Uwielbiam podejście BDD do rozwoju, ale wpadłem na troskę o to, jak daleko zajść. Ten komentarz z ThoughtWorks najnowszyRadar daje mi przerwę:

„Pojawienie się ram testowych opartych na zachowaniu (BDD), takich jak Cucumber, w połączeniu z narzędziami do automatyzacji przeglądarek, takimi jak Selenium, zachęciło do powszechnego stosowania testów akceptacyjnych na poziomie przeglądarki. Testy są największe, zamiast tego powinniśmy przetestować na odpowiednim poziomie, jak najbliżej kodu, aby testy mogły być prowadzone z maksymalną wydajnością Testy na poziomie przeglądarki powinny być wisienką na torcie, wspieraną przez akceptację i jednostkę testy wykonywane na odpowiednich warstwach. ”

Oto mój scenariusz (gra słów):

Mam podstawową aplikację CRUD z wymogiem biznesowym do filtrowania wyświetlanych danych na podstawie kryteriów, które użytkownik końcowy może wybrać. Dla ułatwienia dyskusji powiedzmy, że jest to aplikacja dla firmy energetycznej i wyświetla się bieżące zużycie energii dla każdego miesiąca. Użytkownik tej aplikacji może zawęzić dane, wybierając jednego klienta, wielu klientów, żadnych klientów lub „Wszystkich klientów”. Wyświetlane dane zmieniają się w zależności od tego, co wybiorą.

Dla interesariuszy produktowych stanowią one naprawdę 4 oddzielne scenariusze. Jednak z perspektywy programisty są praktycznie identyczne, a jedyną różnicą jest parametr przekazany do DB. Pojawia się więc pytanie: czy korzyść z wypisania każdej permutacji przewyższa koszt jej uruchomienia i utrzymania?

Myślę, że zasady BDD prawdopodobnie powiedzą „tak”, ponieważ komunikacja oczekiwanego zachowania jest bardziej wyraźna, ale nie jestem pewien. Z pewnością ma dla mnie poczucie przesady. Najprawdopodobniej w scenariuszach będzie dużo kopiowania i wklejania z niewielkimi zmianami.

Moim zamiarem jest objęcie tej funkcji jednym scenariuszem, który odzwierciedla podstawową wartość biznesową („kiedy wybieram klienta, którego widzę dane dotyczące zużycia energii”), a następnie obejmuje inne permutacje zestawem testów integracyjnych nieopartych na interfejsie użytkownika sprawdzanie poprawności usługi / zapytania zwraca poprawne dane. Czy to myślenie jest złe? Jaka jest najlepsza odpowiedź na pytanie, czy te scenariusze są objęte, bez rezygnowania z zalet BDD?