Idź do:
Czym jest Behavior-Driven Development?
BBD, czyli Behavior-Driven Development, to zwinny proces rozwoju oprogramowania determinowany zachowaniem, ukierunkowany na spełnienie określonych wymagań. BDD jest procesem wytwarzania oprogramowania, w którym dokumentacja i testy są pisane w języku naturalnym. W idealnym świecie BDD powinno być integralną częścią całego cyklu wytwarzania oprogramowania. Funkcjonalności powinny być opisane w służącym do tego celu języku Gherkin jeszcze na etapie zbierania wymagań i analizy, a następnie wykorzystywane (ewentualnie rozwijane) w fazie projektowania i implementacji. Rozpoczynając testy manualne, tester opiera się na istniejącej dokumentacji, która w jasny sposób pokazuje mu warunki początkowe, wszystkie niezbędne akcje i ich finał. Następnie na jej podstawie tworzone są testy automatyczne z zachowaniem języka naturalnego. Tester otrzymuje zadanie do przetestowania manualnego / napisania testu automatycznego i dzięki czytelnej formie zapisu wie, czym ma się zająć, a interpretacja zadania nie powinna być problemem. Czy zawsze tak jest? Postaram się odpowiedzieć na to pytanie w dalszej części.
TDD vs. BDD
Behavior-Driven Development często jest porównywany do podejścia TDD. Test-Driven Development także jest zwinnym procesem testowania oprogramowania. Opiera się na powtarzaniu cyklu Red – Green – Refactoring. Rozwój oprogramowania opiera się tu na testach napisanych dla jeszcze nieistniejących funkcjonalności. Podstawową różnicą między BDD od TDD jest wykorzystanie w BDD zrozumiałego dla wszystkich – nawet osób bez wiedzy technicznej – języka, co pokazuje przykład poniżej.
Keep it simple, czyli zalety BDD
Oto fragment wymagań, które są równocześnie prawdziwym (nie pseudo-) kodem:
Scenario: User add article Given: User is logged in When: User add new article Then: Article should be displayed
Zalety takiego podejścia widać od razu.
Tak skonstruowana dokumentacja, wykorzystująca język naturalny, jest dostępna dla wszystkich w projekcie i wspiera rozwój aplikacji na różnych etapach. Członkowie zespołu mogą omawiać ją na spotkaniach przed implementacją i w jej trakcie, a następnie wykorzystać w testach automatycznych i raportach (jeżeli są generowane), aby czytelnie zobrazować stan aplikacji. Także osoby niemające wiedzy technicznej, np. przedstawiciele biznesu, mogą mieć wgląd w to, jakie ścieżki biznesowe są pokryte przez testy automatyczne. Dzięki temu mogą sprawdzić, czy aplikacja od samego początku jest wytwarzana zgodnie z celem biznesowym.
Jednak w rzeczywistości może to wyglądać zupełnie inaczej.
Ciemna strona mocy, czyli BDD w praktyce
Przejdźmy teraz od teorii do praktyki. Czasem założenie projektowe co do stosowania BDD rozmija się z realizacją. Przykładowo dzieje się tak, gdy podejście BDD jest wykorzystywane tylko w przypadku testów. W rezultacie BDD przestaje być procesem wytwarzania oprogramowania, stając się jedynie formą pisania testów automatycznych. Jak unikać takich sytuacji i jakie są najczęstsze przyczyny błędów w wykorzystaniu Behavior-Driven Development?
Najczęstsze błędy w wykorzystaniu BDD
- Biznes nie dostarcza gotowych scenariuszy w formie „Given, When, Then”
Powody są różne: potrzebny jest dodatkowy czas, a więc koszt, brakuje chęci lub kompetencje odpowiedzialnych osób są niewystarczające. Product Owner zazwyczaj dostarcza wymagania w języku najbardziej zrozumiałym dla niego, a późniejsze tłumaczenie na Gherkin schodzi na dalszy plan. W takiej sytuacji tester nie ma możliwości skopiowania tekstu i wykorzystania go bezpośrednio w kodzie. Praca, która powinna była być wykonana na dużo wcześniejszym etapie projektowym, spada na testera. Zamiast skupić się na testowaniu, musi on zająć się przepisywaniem wymagań.
- Scenariusz testów jest tworzony po czasie
Podobnie jak w TDD, tak i w BDD testy powinny prowadzić wytwarzanie oprogramowania. Nie można jednak tego osiągnąć, gdy scenariusz jest tworzony po czasie, a nie, zgodnie ze sztuką, przed napisaniem danej funkcjonalności. Problemem jest również brak równoległej pracy testera i developera. Jeżeli scenariusz nie został dostarczony wcześniej, tester tworzy go częściowo na podstawie dokumentacji, a częściowo na podstawie tego, co stworzył programista. W rezultacie testy dopracowywane są dopiero na końcu, przed zamknięciem Sprintu, a testerzy dwoją się i troją, aby przetestować funkcjonalność i zamknąć wszystkie zadania.
- Biznes nie jest zainteresowany treścią testów
Pisałem o tym, że silnym argumentem, który przemawia za stosowaniem BDD, jest możliwość czytania takich testów przez osoby niemające wiedzy technicznej. W praktyce nigdy nie spotkałem się z tym, aby biznes był zainteresowany treścią testów. Przedstawiciele biznesu chętniej zaglądają do raportów i kolorowych wykresów. Zazwyczaj Product Owner pyta zespół o stan aplikacji, o to, czy dana funkcjonalność jest gotowa, czy są jakieś błędy, które należy poprawić. Pełna treść raportów z testów jest znana tylko testerom, tylko oni je monitorują, utrzymują, rozwijają. Gdyby osoby bez wiedzy technicznej chętniej czytały testy, komunikacja w projekcie rzeczywiście byłaby łatwiejsza. Dodatkowo, takie osoby zyskałyby wiedzę, jak przekazywać wymagania w bardziej przystępny dla testerów sposób, co umożliwiłoby szybszy start projektu.
Czytamy test
Załóżmy jednak czysto teoretycznie, że ktoś bez znajomości programowania chciałby zobaczyć, co w testach piszczy. Czy na pewno pełna forma BDD jest jedynym wyjściem? Poniżej fragment kodu zapisany w Javie z wykorzystaniem frameworku Serenity BDD (jednak bez wykorzystania jego możliwości pracy z językiem Gherkin):
@Test
public void itShouldBePossibleToAddNewArticle () {
// Given
loginPageSteps.signInUser(testUser);
navBarSectionSteps.clickNewPost();
// When
editorPageSteps.addArticle(defaultArticle);
// Then
articlePageSteps.articleShouldBeDisplayed(defaultArticle);
}
Jak widać, nie potrzeba wiedzy programistycznej, aby z tych kilku linijek kodu zrozumieć, że potrzebne jest logowanie, dodanie artykułu oraz sprawdzenie jego widoczności. Poniżej raport, jaki został wygenerowany. Zauważmy, że metody jak np. „clickNewPost()” są automatycznie przetwarzane na tekst „Click new post”:
Zwykły kod, jeśli jest odpowiednio przygotowany, również może być w łatwy sposób analizowany przez osoby bez znajomości programowania. Nie mówiąc o narzędziach, takich jak Serenity BDD czy Allure, które pomagają wygenerować raporty. Teoretycznie, jeśli biblioteka kroków jest dobrze rozbudowana, to nawet osoba bez wiedzy programistycznej mogłaby dodawać kolejne testy. Ten argument jest jednak trudny do spełnienia, ponieważ zazwyczaj trzeba dodać także nowe metody ponad te, które już istnieją. Zwykle można wesprzeć się częściowo istniejącą implementacją, ale tu już jest niezbędna znajomość programowania.
BDD a czas
Pisałem o tym, jak ważne jest, aby podejście BDD stosować wyłącznie całościowo, na każdym etapie. Jest jeszcze jeden bardzo ważny argument, który w mojej ocenie przemawia na niekorzyść stosowania BDD w samych testach – czas. BDD nakłada kolejną warstwę abstrakcji w tworzonym kodzie, a to z kolei wymaga poświęcenia dodatkowego czasu na jej zrozumienie, stworzenie i utrzymanie. Trzeba więc albo dodatkowych osób w projekcie, albo testerzy, zamiast tworzyć nowe testy oraz na bieżąco utrzymywać istniejące, zajmują się pielęgnacją BDD, tak aby testy były czytelne dla osób… które w rzeczywistości ich nie czytają.
BDD: tak czy nie?
BDD stało się hasłem modnym, szeroko reklamowanym i obecnie Internet pęka w szwach od treści zachwalających to podejście. Decyzja o wykorzystaniu BDD (czy jakiegokolwiek innego podejścia) w projekcie nie powinna być jednak podejmowana z powodu chęci podążania za modą, ale na podstawie dogłębnej analizy. Problemem może być również sytuacja, gdy metodologia BDD jest stosowana częściowo. BDD spełni swoje zadania, jeśli będzie implementowane właściwie w całościowym procesie wytwarzania oprogramowania, zatem już od momentu zbierania wymagań. Jeżeli chcemy z niego korzystać tylko w automatyzacji testów, bez przeprowadzenia dogłębnej analizy, BDD niekoniecznie musi okazać się dobrym rozwiązaniem w każdym projekcie. W dużym uproszczeniu, jeżeli celem testów ma być poruszanie myszką i wpisywanie tekstu, z łatwością można znaleźć inne narzędzia, które zrobią to równie dobrze, oszczędzając przy tym sporo czasu. To moja prywatna opinia zebrana w czasie różnych doświadczeń w karierze testera. Wierzę jednak, że nie brakuje przykładów poprawnej implementacji BDD, a mój tekst także przyczyni się do wzrostu świadomości w tym zakresie.
Q&A
Pytanie:
„Jeżeli chcemy z niego korzystać tylko w automatyzacji testów, bez przeprowadzenia dogłębnej analizy, BDD niekoniecznie musi okazać się dobrym rozwiązaniem w każdym projekcie. W dużym uproszczeniu, jeżeli celem testów ma być poruszanie myszką i wpisywanie tekstu, z łatwością można znaleźć inne narzędzia, które zrobią to równie dobrze, oszczędzając przy tym sporo czasu. To moja prywatna opinia zebrana w czasie różnych doświadczeń w karierze testera. Wierzę jednak, że nie brakuje przykładów poprawnej implementacji BDD, a mój tekst także przyczyni się do wzrostu świadomości w tym zakresie.”
Jakie narzędzia np.? Dopiero poznaje świat automatyzacji i zaintrygowała mnie Twoja opinia. Najczęściej spotykam się z pisaniem scenariuszy w składni Gherkina (Cucumber / JBehave) a potem mapowanie stepów i dopiero implementacja metod na elementach strony – jest to całkiem wygodne – jakie mamy alternatywy?
Odpowiedź:
Przykładowe narzędzia to np. czyste Selenium. Gdybyś jednak chciał korzystać z jakiegoś wrappera, to zdecydowanie polecam Ci Selenide – w zespole testerskim Inetum to narzędzie jest bardzo lubiane. Do raportów dobrym rozwiązaniem będzie Allure.
W 3 krokach, które opisałeś, pierwsze 2 można scalić. Scenariusz piszesz od razu w Javie.
Podam Ci przykład.
1. Rozpisujesz testy, dodając czytelne nazwy
@Test
public void itShouldBePossibleToAddComment() {
}
2. Dodajesz Given When Then
@Test
public void itShouldBePossibleToAddComment() {
//Given
//When
//Then
}
3. Rozpisujesz scenariusz w Javie
@Test
public void itShouldBePossibleToAddComment() {
//Given
articlePage.pageIsOpened();
//When
articlePage.addComment(comment);
//Then
articlePage.commentShouldBeDisplayed();
}
4. Implementujesz metody z kroku 3.
Taki kod powinna zrozumieć także osoba nietechniczna. A gdyby było to problemem, to w Allure istnieje adnotacja @Step. I teraz jeśli do metody:
commentShouldBeDisplayed();
dodasz adnotację @Step(„Komentarz powinien być widoczny”)
to kod będzie wyglądał tak:
Public class ArticlePage {
@Step(„Komentarz powinien być widoczny”)
public void commentShouldBeDisplayed() {
//implementacja metody
}
}
A w raporcie Allure ten krok będzie widoczny jako „Komentarz powinien być widoczny”.
Przerobiłem przykładowy raport, żeby lepiej to zobrazować:
Przydatne linki:
Tomasz zajmuje się automatyzacją testów aplikacji webowych oraz mobilnych. Jest absolwentem Politechniki Krakowskiej oraz Uniwersytetu Jagiellońskiego. Prywatnie mąż wspaniałej kobiety.