Jak zacząć automatyzować testy?

Jak zacząć automatyzować testy?

Ciągłe dostarczanie (ang. continuous delivery) towarzyszy mi w zasadzie od zawsze. Są jednak firmy, które dopiero dziś chcą zmienić swój cykl dostaw na ciągły. Zdecydowanie łatwiej zacząć od zera. Pytanie, co zrobić gdy system już jest?

Każde dobre środowisko do continuous delivery powinno spełnić dwa warunki. Po pierwsze zmiany są propagowane automatycznie, aby wyeliminować ryzyka związane z błędami ludzkimi przy kopiowaniu i łączeniu plików. Po drugie, zmiany, które chcemy dostarczyć, działają z już dostarczonym kodem, a może precyzyjniej – nie psują uprzednio uruchomionej funkcjonalności.

I dziś o tym jak spełnić ten drugi warunek.

Czystość repozytorium współdzielonego

Zasadniczo testować można manualnie. Nie trzeba wówczas bawić się w pisanie i utrzymywanie testów. Teoretycznie można byłoby mieć zatem continuous delivery bez testów automatycznych. Teoretycznie. Jeśli jesteśmy w stanie dla każdej nawet najmniejszej wersjonowanej zmiany przeklikać ręcznie wszystkie scenariusze testowe w sensownym czasie, na przykład jedna godzina, to automatyzacja takiego zestawu testów nie opłacałaby się i moglibyśmy zostać przy manualach.

Tyle teoria. Praktyka pokazuje, że taka sytuacja w przyrodzie występuje stosunkowo rzadko. W firmach, rozwijających swoje systemy latami, w zasadzie prawie nigdy. Często przejście przez wszystkie scenariusze testowe manualnie zajmuje nawet kilka tygodni. Te klika tygodni na zamknięcie jednej wersji jest sporym ograniczeniem częstotliwości dostarczeń, dlatego też potrzebna jest automatyzacja.

Ale nie tylko. Dostarczanie zmian w świecie continuous delivery opieramy na czystości wersji w repozytorium współdzielonym. Oznacza to, że każdy “commit” przed udostępnieniem w repozytorium,  powinien przejść cały zestaw testów. Dzięki czemu w repozytorium znajdzie się jedynie kod, który te testy przechodzi z wynikiem pozytywnym, a co za tym idzie, każdy pobierający ma gwarancję jego działania. Na pewności tej oparta jest też decyzja o udostępnieniu konkretnej wersji repozytorium na środowisku produkcyjnym.

Od czego zacząć automatyzację testów?

Każdy programista, który choć raz musiał pisać testy do odziedziczonego kodu wie, że nie zawsze automatyzacja jest możliwa, bez radykalnej zmiany projektu organizacji kodu. Na szczęście nie jest to jedyne rozwiązanie na początku prac nad automatyzacją.

W praktyce programistycznej przyjęło się, że pozytywny wynik testu oznacza “działanie” programu. Przez co często zapominamy, co i jak tak na dobrą sprawę testujemy. Trochę nie wiedzieć czemu przyzwyczailiśmy się do podziału: testy jednostkowe (ang. unit) sprawdzają klasy, komponentowe komponenty, systemowe systemy, integracyjne współdziałanie klas, komponentów czy systemów, itd.

A co z działaniem programu? Przecież są jeszcze testy funkcjonalności (nie mylić z funkcjonalnymi), zwane też testami akceptacyjnymi lub użytkownika. Automatyzację proponuje zacząć właśnie od scenariuszy testów funkcjonalności.

Być może w Waszej organizacji pod nazwą “testy funkcjonalności” kryją się jeszcze jakieś inne testy. Mnie jednak chodzi o pierwotne znaczenie słowa “feature” (z ang. funkcjonalność). Tłumacząc dosłownie feature to “cecha”. Aby nie komplikować sobie słownika, możecie zaproponować nowy rodzaj testów: testy cechy.

Przystępując do testowania cechy, warto określić po czym poznamy, że program ma daną cechę i w teście zapisać właśnie takie sprawdzenia. Nie powinniśmy się przejmować dyskusją na temat tego czy ten test jest jednostkowy czy systemowy. Ważne, że wiemy, co sprawdza.

Oczywiście, wyniki testów cech nie dadzą odpowiedzi na pytanie, który komponent czy funkcja działa niezgodnie z wymaganiami. Ale też z punktu widzenia zasady czystości repozytorium, nie musimy tego wiedzieć. Zestaw testów cech odpalany jest dla konkretnej zmiany, konkretnego commita. Jeżeli testy nie przeszły, to problem tkwi w tej zmianie. Tym samym, programista będzie mieć informację zwrotną, że jego commit zmienia cechę, np. psuje funkcjonalność. I na tym nam zależy.