BDD w Scali - Czy to musi być brzydkie?

Question

Używam lettuce dla Pythona w przeszłości. Jest to prosty framework BDD, w którym specyfikacje są zapisywane w zewnętrznym pliku tekstowym. Implementacja używa wyrażenia regularnego do identyfikowania każdego kroku, potwierdzając kod wielokrotnego użytku dla każdego zdania w specyfikacji.

Używanie scala, albo z specs2 lub scalatest Jestem zmuszony napisać specyfikację wraz z implementacją, uniemożliwiając ponowne wykorzystanie implementacji w innym teście (na pewno możemy go zaimplementować gdzieś w funkcji) i nie można oddzielić implementacji testowej od samej specyfikacji (coś, co kiedyś robiłem, dostarczając klientom testów akceptacyjnych do sprawdzania poprawności).

Podsumowując, podniosłem moje pytanie: biorąc pod uwagę znaczenie sprawdzania poprawności testów przez klientów, czy istnieje sposób w ramach BDD dla scala, aby załadować testy z zewnętrznego pliku, podnosząc wyjątek, jeśli zdanie w teście nie jest zaimplementowane a mimo to wykonanie testu normalnie, jeśli wszystkie zdania zostały zaimplementowane?

Answer 1

Właśnie odkryłem cucumber plugin for sbt. Testy będą realizowane w ramach testu/scala, a specyfikacje będą przechowywane w testach/zasobach jako zwykłe pliki txt. Po prostu nie jestem pewien, na ile wiarygodna jest biblioteka i czy będzie ona miała wsparcie w przyszłości.

Edycja: Powyższe jest opakowaniem dla następującej wtyczki, która doskonale rozwiązuje problem i obsługuje Scala. https://github.com/cucumber/cucumber-jvm

Answer 2

Sam powiedziałeś, że łatwo jest dokonać implementacji wielokrotnego użytku normalnymi metodami Scala zapewnia tego rodzaju stuf (metody, funkcje, cechy, klasy, typy ...), więc nie ma tak naprawdę tam jest problem.

Jeśli chcesz podać wersję bez kodu dla swojego klienta, nadal możesz dać im pliki kodu, a jeśli nie mogą zignorować małej składni, prawdopodobnie możesz napisać niestandardowy reporter zapisujący cały tekst na plik, może nawet sformatowany jako html lub coś podobnego.

Inną opcją byłoby użycie JBehave lub dowolnej innej architektury opartej na JVM, powinny one pracować ze Scala bez problemu.

Answer 3

Tu chodzi o kompromisy. Specyfikacje w stylu ogórka są świetne, ponieważ jest to czysty tekst, który łatwo można edytować i czytać przez osoby nie posiadające koderów.

Są one jednak również dość sztywne, ponieważ narzucają ścisły format oparty na funkcjach i "Kiedy i kiedy". W specs2 for example możemy napisać dowolny tekst, który chcemy, i opisać tylko linie, które mają być działaniami w systemie lub weryfikacją. Wadą jest to, że tekst staje się adnotowany i że musi być jednoznacznie określony, aby wskazać to, co jeszcze nie zostało zaimplementowane. Również adnotacja jest po prostu odwołaniem do jakiegoś kodu, gdzieś mieszka i można oczywiście użyć zwykłych technik programowania, aby uzyskać ponowne wykorzystanie.

BTW, link above jest interesującym przykładem kompromisu: w tym pliku, pierwsza specyfikacja jest „brzydsze”, ale jest więcej czasu kompilacji sprawdza, że ​​etap When wykorzystuje informacje z etapu Given albo my nie ma sekwencji następujących kroków: Then -> When. Druga specyfikacja jest ładniejsza, ale także bardziej podatna na błędy.

Następnie pojawia się kwestia zachowania wyrażeń regularnych. Jeśli istnieje ścisły rozdział między osobami piszącymi funkcje a osobami je wdrażającymi, bardzo łatwo jest przerwać implementację, nawet jeśli nic istotnego się nie zmieni.

Wreszcie pojawia się kwestia kontroli wersji. Kto jest właścicielem dokumentu? Jak możemy się upewnić, że kod jest zsynchronizowany ze specyfikacją? Kto refaktoryzuje specyfikację, gdy jest to wymagane?

Nie ma, jak dotąd, doskonałego rozwiązania. Mój wniosek jest taki, że artefakty BDD powinny znajdować się w rękach programistów i być weryfikowane przez innych interesariuszy, czytając kod bezpośrednio, jeśli jest on czytelny lub czyta wynik w formacie html/pdf. A jeśli artefakty BDD są własnością programistów, mogą równie dobrze używać własnych narzędzi, aby ułatwić sobie życie dzięki weryfikacji (za pomocą kompilatora, jeśli to możliwe) i konserwacji (przy użyciu zautomatyzowanych refaktoryzacji).

Answer 4

Głównym kryterium projektowym Eric było trwałości rozwoju specyfikacji wykonywalnej (poprzez refaktoryzację), a nie początkowej wygody ze względu na "piękno" prostego tekstu.

zobaczyć http://etorreborre.github.io/specs2/

The cechy specs2 są:

1. równoczesnego wykonywania przykładów domyślnie
2. właściwości ScalaCheck
3. kpi z Mockito
4. tabele danych
5. AutoExamples, gdzie kod źródłowy jest wyodrębniany w celu opisania przykładu
6. Bogata biblioteka dopasowujących
7. łatwo tworzyć i komponować
8. użytkowa z moszczu i powinny
9. Wracając „funkcjonalny” wyniki lub rzucanie wyjątki
10. wielokrotnego użytku poza specs2 (w badaniach JUnit na przykład)
11. Formy do pisania Fitnesse podobny specyfikacji (z Markdown znaczników) raportowanie
12. HTML do tworzenia dokumentacji testów akceptacyjnych, aby utworzyć instrukcję
13. Fragmenty dotyczące dokumentacji API z zawsze aktualnych kodów
14. integracja z SBT i JUnit narzędzi (Maven, IDE, ...)

Specs2 jest imponująca zarówno w projektowaniu i implementacji. Jeśli przyjrzysz się uważnie, zobaczysz, że DSL może zostać przedłużony, podczas gdy zachowasz bezpieczeństwo i niezawodność kodu domeny.

Ten, kto zostawia na boku argument "jest bardziej brzydki" i próbuje tego poważnie, znajdzie moc. Zamówienie formularzy i fragmentów danych