Co to jest TDD i ATDD?

W tym artykule podkreślamy podobieństwa i różnice pomiędzy dwoma popularnymi metodami testowania powszechnie znanymi jako TDD i ATDD.

TDD oznacza test-driven development, podczas gdy ATDD oznacza acceptance test-driven development. Zrozumienie jak te dwa podejścia do testowania działają jest krytyczne dla profesjonalistów zajmujących się testowaniem i ten post będzie elementarzem, który pozwoli ci zacząć odkrywanie obu. Zrozumiesz TDD vs ATDD.

Co to jest Test-Driven Development (TDD)?

TDD jest systemem rozwijania oprogramowania zgodnie z zasadami Extreme Programming (XP), jednak z czasem wyodrębnił się jako niezależna technika rozwoju oprogramowania.

W TDD, testy jednostkowe są przeprowadzane bezpośrednio na kodzie źródłowym.

Po pierwsze, tester pisze automatyczny przypadek testowy, który definiuje pożądaną funkcję, którą system powinien idealnie wykonać, ale celowo projektuje przypadek testowy w taki sposób, że nie może on być spełniony przez system w jego obecnym stanie.

Po drugie, deweloper notuje powody, dla których system nie spełnił testu i wypisuje kod potrzebny do refaktoryzacji systemu i umożliwienia mu przejścia go w drugiej próbie. Proces ten jest podsumowany na poniższej grafice.

Proces TDD jest kontynuowany w ten sposób, zygzakując pomiędzy porażką a sukcesem, tak, że każda iteracja popycha system do jego granic, a następnie pomaga mu je przezwyciężyć poprzez informacje zwrotne, które są generowane.

TDD jest eksperymentem w dobrowolnej porażce i wymaga trochę odwagi, aby owinąć głowę wokół tej sprzecznej z intuicją techniki. Jednakże, kiedy już to zrobisz, zostaniesz nagrodzony prostą, ale bardzo skuteczną metodą zwalczania strachu przed porażką podczas testowania, jednocześnie poprawiając swoją pracę.

Co to jest Acceptance Test-Driven Development (ATDD)?

ATDD jest metodą testowania opartą na współpracy, która zmusza wszystkie osoby zaangażowane w tworzenie nowego oprogramowania (np.testerów, programistów i użytkowników) do zdefiniowania jako zespół kryteriów akceptacji, które system musi spełnić we wczesnych fazach rozwoju.

Punktem tego kroku jest zapewnienie, że wszyscy ci interesariusze zgadzają się co do głównych celów projektu, szczególnie w zakresie funkcjonalności, której może oczekiwać użytkownik końcowy. Podczas tej fazy ATDD, techniki takie jak user personas i user stories mogą być bardzo pomocne.

Gdy testy akceptacyjne zostaną ostatecznie uruchomione na systemie, niepowodzenia są odnotowywane, a programiści następnie refaktoryzują wadliwe komponenty, pisząc kod potrzebny do spełnienia kryteriów akceptacji przy następnej próbie.

Proces ten jest przeprowadzany iteracyjnie, zwykle na końcu każdego sprintu, aż do momentu, gdy produkt końcowy jest gotowy do wdrożenia. Poniższa grafika to wyjaśnia.

ATDD zapewnia zespołowi jaśniejszą wizję tego, jak produkt końcowy będzie działał, pozwalając wszystkim pozostać skupionym na długoterminowych celach, zamiast gubić się w poszczególnych liniach kodu.

Podsumowanie

Teraz masz dobre zrozumienie podstawowych różnic pomiędzy TDD i ATDD. Te dwie metody testowania są blisko spokrewnione, jednak ATDD zawiera również testy akceptacyjne w procesie i kładzie większy nacisk na współpracę w zespole niż TDD.

Oba podejścia ładnie pasują do zasad agile, ponieważ oba zachęcają do zbierania informacji zwrotnych, aby budować na wcześniejszych błędach. Ponieważ stale refaktoryzujesz system i zajmujesz się problemami, które napotkałeś w poprzedniej próbie, metody te pomagają Ci rozwijać bardziej wartościowy produkt końcowy w sposób przyrostowy.

Dołącz do 60 000+ subskrybentów

Dla najnowszych blogów, aktualizacji branżowych i ekskluzywnych wskazówek.

*Twój e-mail jest u nas bezpieczny, nienawidzimy spamu

.