Podejście do rozwoju opartego na testach w zwinnej produkcji oprogramowania

Teraz ludzie często mówią o zwinnej produkcji.

Czym jest zwinny rozwój?

Zwinny rozwój jest zdolnością do rozwoju oprogramowania, która odpowiada na szybko zmieniające się potrzeby. Ich konkretne nazwy, koncepcje, procesy i terminologia różnią się. W porównaniu do „niezwinny,” kładą nacisk na bliską współpracę między zespołami programistów a ekspertami biznesowymi, komunikację twarzą w twarz (uznawaną za bardziej efektywną niż dokumentacja pisemna) oraz częste dostarczanie nowych wersji oprogramowania, małych i zespoły samoorganizujące się do pisania małych i wartościowych funkcji oraz podejść do organizacji zespołu, które dostosowują się do zmieniających się potrzeb, z większym naciskiem na rolę ludzi w rozwoju oprogramowania.

Jednak istnieje kilka podobnych wersji metod rozwoju zwinnego TDD, takich jak TDD: BDD, DDD i ATDD. Pozwól, że krótko przedstawię te metody, zanim szczegółowo omówię TDD:

TDD: Rozwój oparty na testach

Rozwój oparty na testach (TDD) to proces rozwoju oprogramowania, który polega na przekształcaniu wymagań oprogramowania w przypadki testowe przed całkowitym opracowaniem oprogramowania oraz śledzeniu całego rozwoju oprogramowania poprzez wielokrotne testowanie oprogramowania dla wszystkich przypadków testowych. To jest przeciwieństwo rozwijania oprogramowania najpierw, a następnie tworzenia przypadków testowych. Niektóre popularne modele bardzo dobrze wspierają TDD, takie jak MVC i MVP.

BDD: Rozwój oparty na zachowaniu (Behavior Driven Development)

Rozwój oparty na zachowaniu (BDD) to również zwinny proces rozwoju oprogramowania. Zachęca do współpracy między programistami, testerami zapewnienia jakości i przedstawicielami klientów w projektach oprogramowania. Zachęca zespoły do korzystania z rozmów i konkretnych przykładów, aby sformalizować wspólne zrozumienie, jak aplikacja powinna działać. Pochodzi z rozwoju opartego na testach (TDD).

ATDD: Rozwój oparty na testach akceptacyjnych

Aby promować realizację funkcjonalnego kodu poprzez przypadki testowe jednostkowe, zespół musi zdefiniować oczekiwane standardy jakości i zasady akceptacji oraz promować praktykę TDD programistów i wydajność testerów poprzez jasny i spójny plan testów akceptacyjnych (w tym serię scenariuszy testowych). Dla programistów kładzie nacisk na to, jak wdrożyć system i jak go testować.

DDD: Projektowanie oparte na domenie

DDD odnosi się do projektowania opartego na domenie, tj. rozwoju opartego na domenie. DDD jest w rzeczywistości zbudowane na tym fundamencie, ponieważ koncentruje się na projektowaniu warstwy usług, skupia się na wdrożeniu biznesowym, łączy analitykę i projektowanie oraz nie utrzymuje tego w podzielonym stanie, aby poprawnie i kompleksowo wdrożyć potrzeby klientów i zbudować model skalowalności biznesu.

Plan wdrożenia TDD

Poprzez testowanie promujemy cały rozwój, ale rozwój oparty na testach to nie tylko prosta praca testowa, ale proces kwantyfikacji analizy wymagań, projektowania i kontroli jakości.

Zasady rozwoju

Najpierw napisz kod testowy, a następnie napisz kod funkcji.

1. Napisz kod testowy zgodnie z dokumentem wymagań, a nie w celu zrealizowania funkcji;
2. Nie chciej być gruby jednym kęsem. Podczas testowania dużych bloków funkcjonalnych, najpierw powinieneś podzielić je na mniejsze bloki funkcjonalne do testowania;
3. Pamiętaj, aby nie pisać kodu w celu ukończenia funkcji, użyj najprostszego możliwego kodu do wdrożenia funkcji;
4. Jeśli wymagania mogą być testowane, napisz kod testowy i zrezygnuj z tych, które nie mogą być testowane lub uważasz, że nie muszą być testowane;
5. Przed zmianą/dodaniem jakiegokolwiek kodu funkcji, musisz najpierw pomyśleć, czy chcesz zmienić/dodać przypadki testowe;
6. Kod funkcji/testu, nierozsądna struktura, zduplikowany kod itp., refaktoryzuj na czas po przejściu testu.

Proces rozwoju TDD

1. Analizuj i określ docelowy scenariusz testowy;
2. Dodaj test jednostkowy, aby zweryfikować wejście i wyjście scenariusza testowego;
3. Uruchom test i uzyskaj wynik nieudanego testu;
4. Napisz najprostszy kod funkcji, aby przejść test;
5. Uruchom test ponownie i zobacz, że test przeszedł;
6. Przeprowadź refaktoryzację kodu, w tym kodu funkcjonalnego i kodu testu jednostkowego;
7. Powtarzaj powyższe kroki, aż rozwój zostanie zakończony.

Korzyści z TDD

1. Zmniejsz obciążenie programistów. Dzięki jasnemu procesowi skupmy się tylko na jednym punkcie na raz, a obciążenie myślenia jest mniejsze.
2. Sieć ochronna. Pełne testowanie jednostkowe zapewnia sieć ochronną dla kodu produktu, co ułatwia dostosowanie się do zmian w wymaganiach lub poprawę projektu kodu. Więc jeśli wymagania twojego projektu są stabilne, zrealizowane za jednym razem i nie ma późniejszych zmian, korzyści z TDD są mniejsze.
3. Wyjaśnij wymagania z wyprzedzeniem. Pisanie testów najpierw może pomóc nam pomyśleć o wymaganiach i wyjaśnić szczegóły wymagań z wyprzedzeniem, zamiast odkrywać niejasne wymagania dopiero w połowie kodu.
4. Szybka informacja zwrotna. Wiele osób mówi, że podczas TDD moja objętość kodu wzrasta, więc wydajność rozwoju maleje. Jednak jeśli nie masz testów jednostkowych, musisz testować je ręcznie, spędzasz dużo czasu na przygotowywaniu danych, uruchamianiu aplikacji, modyfikowaniu interfejsów itp., a informacja zwrotna jest wolna. Dokładniej mówiąc, szybka informacja zwrotna to korzyść z testowania jednostkowego.