Byłem w wielu zespołach, które próbują ćwiczyć metodyki zwinne i często te zespoły koncentrują się na testach. Czy testowanie jest niezbędną częścią ćwiczenia metodologii Agile, czy jest to tylko praktyka XP, która jest stosowana od lat?

Testowanie jest absolutnie niezbędne dla zwinności, przede wszystkim dlatego, że zwinność opiera się na stopniowych ulepszeniach: trudność polega na tym, że czasami trudno jest zobaczyć, jak bieżące zmiany wpłyną na twój stary kod. Najlepszym sposobem, aby mieć pewność, że niczego nie popsułeś, jest przetestowanie go i poznanie JAK to przetestować. W ten sposób natychmiast znajdziesz błąd, a nie później, gdy zapomnisz dokładnie, co zrobiłeś, pisząc kod, który złamał jakąś starą funkcję.

Powodem, dla którego różni się to od bardziej tradycyjnego programowania typu odgórnego, jest to, że w tym środowisku a) bardzo trudno jest go przetestować, dopóki nie ma gotowego produktu b) teoretycznie rozważa się wszystkie kryteria projektowe w tym samym czasie, i więc jest mniej prawdopodobne, że podejmie decyzję projektową, która złamie poprzednie decyzje projektowe.

Prawdopodobnie mówisz o testach automatycznych, testach jednostkowych, testach integracyjnych itp. Są one ważniejsze dla zwinnego niż testowanie ręczne (z testerami itp.), Ponieważ są zbyt wolne, dlatego nie można przetestować każdej drobnej zmiany, którą wprowadzasz. Ponieważ zwinność polega na szybkich małych iteracjach, bardzo przydatne są testy weryfikujące poprawność w sekundach lub minutach, a nie godzinach czy dniach.

Jeśli nie masz testów, skąd wiesz, że działa Twój kod?

Edycja: twierdzenie, że testy nie mogą udowodnić, że kod działa, nie definiuje jednego kluczowego terminu, a mianowicie działa . Co to znaczy, że program działa? Jeśli ten termin jest niejasny, nie ma żadnego sposobu, aby udowodnić lub upewnić się, że jakiś program działa. Zawsze.

Z drugiej strony możesz zdefiniować dzieła jako „zachowuje się zgodnie ze specyfikacją”. Teraz możesz nie tylko używać testów do wykazania, że ​​kod działa, ale same testy mogą służyć jako wykonywalna specyfikacja zachowania twojego kodu. Innymi słowy, dobrze napisany zestaw testów określa, co działa .

Ten sposób myślenia zmusza cię również do ponownego zbadania znaczenia błędu . Jeśli kod przejdzie wszystkie testy, oznacza to, że nie ma żadnych błędów w kodzie. Jeśli mimo to system nie zachowuje się tak, jak powinien, jego zachowanie nie jest poprawnie określone. I. e. błąd znajduje się w specyfikacji określonej przez testy.

Takie podejście do tworzenia oprogramowania oddziela funkcjonalną specyfikację systemu od jego wdrożenia, co według każdej książki o inżynierii oprogramowania na świecie jest bardzo dobrą rzeczą. Jednocześnie takie podejście zapewnia, że ​​twoja implementacja zawsze odpowiada specyfikacji funkcjonalnej.

Nie, to nie jest konieczne"

Te zasady Agile nic nie mówią bezpośrednio o testowaniu.

Ale jest wysoce wskazane

Biorąc pod uwagę zaangażowanie Agile w zrównoważony proces, ciągłą / przyrostową dostawę i jakość oprogramowania, automatyczne testowanie jest najlepszym rozwiązaniem dostępnym obecnie dla większości projektów

Wyjątki (jak zauważył Jörg W Mittag) obejmują sprawdzalne narzędzia programistyczne, systemy metaprogramowania, które generują kod, i in. Ale tego rodzaju systemy są rzadkie.

Zarówno Agile, jak i XP starają się unikać Big Design Up Front . W BDUF, wymagania są zbierane, formalna specyfikacja jest tworzony, następnie kodowanie jest zrobione, a następnie przeprowadzono badanie. Ma to sens w przypadku dobrze zdefiniowanych systemów o krytycznym znaczeniu dla życia i życia, takich jak sprzęt medyczny, sondy kosmiczne itp.

Zwinny unika tego przepływu, ponieważ nie działa dobrze w przypadku problemów, które nie są dobrze zdefiniowane, na przykład „wszelkie zmiany, o które klient prosi w tym tygodniu”. Wciąż potrzebujemy formalnej specyfikacji, więc wiemy, co robić i kiedy skończymy, ale zamiast jakiegoś pisemnego dokumentu używamy kodu w formie automatycznych testów.

Zautomatyzowane testy jednostkowe są szybkie do napisania, szybkie do uruchomienia i bardzo modułowe / odsprzęgnięte. Dzięki temu są szybkim sposobem formalnego określenia i sprawdzenia wymagań.