Testy automatyczne to temat, któremu chciałbym poświęcić dużo uwagi na tym blogu. Będzie więc to pierwszy post z serii, którą roboczo sobie nazwiemy Testy Automatyczne w PHP ( ͡° ͜ʖ ͡°). W dzisiejszym poście „otwierającym” chciałbym opowiedzieć Ci o tym, czym są testy automatyczne i dlaczego warto je pisać.
Mimo wszystko najpierw zacznijmy sobie od pewnej historii. Być może hipotetycznej sytuacji, której sam/a doświadczyłeś/aś.
A było to tak:
To twój pierwszy dzień w pracy. Po krótkim wdrożeniu przez lidera zespołu dostajesz swój pierwszy issue – wszak firma, w której zacząłeś pracę, kultywuje praktykę “first day commit”.
Zabierasz się więc do pracy. Po sklonowaniu repozytorium i postawieniu projektu na firmowym dockerze, dostrzegasz to – P O T Ę Ż N Y projekt. Setki tysięcy linii kodu, monolityczna architektura, skomplikowane struktury danych. Walecznie analizujesz każdy namespace, każdą linię kodu (nawet te zakomentowane w 2017 roku przez osobę, która już dawno tutaj nie pracuje).
Po dwóch godzinach docierasz w końcu do miejsca, które musisz zmodyfikować. Otwierasz klasę o jakże poetyckiej nazwie „EventProccesorThreadResolverAdvisorDecoratorInfoHelperSetter”.
I wtedy dostrzegasz to – wielka metoda na kilkaset linii...
Kątem okiem widzisz niepokojące komunikaty ze strony twoich ulubionych narzędzi do analizy statycznej.
PHPMD krzyczy coś o złożoności cyklomatycznej powyżej liczby 49, PHPCS podświetla wszystko na czerwono.
– Ale super! – myślisz sobie. – W końcu za to mi płacą!
Wytężasz więc umysł, próbując zrozumieć pokrętną logikę kodu, której autorami było 46 deweloperów w przeciągu ostatnich 8 lat.
Na próżno…
I wtedy, dostrzegasz to: katalog Tests/. Z nadzieją w oczach, czym prędzej otwierasz owe directory w swoim IDE, chcąc ujrzeć jego zawartość.
Niestety…
Katalog zawiera jedynie plik o nazwie ExampleTest.php, z bezużytecznym testem o nazwie testItWorksFine…
Myślisz sobie:
tak, odpalenie XDebuga prawdopodobnie będzie twoim kolejnym krokiem… ( ͡° ͜ʖ ͡°)Każdy z nas, deweloperów, prawdopodobnie spotkał się z sytuacją, w której projekt o złożonej logice biznesowej posiadał za mało (lub nie posiadał ich w ogóle) testów automatycznych, które mogłyby wyjaśnić nam specyficzne reguły biznesowe, którymi się rządzi.
Za mało (lub w ogóle), by pomóc nam zbadać stabilność systemu.
Za mało (lub w ogóle), by, sprawdzić, czy implementując nową funkcjonalność, czegoś nie zepsuliśmy.
Nie oszukujmy się. Brak testów w projektach to poważny problem, z którym musimy się zmagać. Nie jesteś przekonany co do tej tezy? Postaram się więc rozwiać Twoje wątpliwości. Zacznijmy jednak od początku i odpowiedzmy sobie na podstawowe pytanie:
Czym jest testowanie oprogramowania?
Z racji, iż lubię czasami kopać w prehistorycznej (lecz wciąż aktualnej, pod wieloma względami) literaturze z lat 70, 80 i 90, zaczniemy sobie od kilku cytatów:
Hetzel, William C.
„Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results” [1]w moim przekładzie:
Testowanie systemu to każda czynność mająca na celu ocenę atrybutu lub zdolności programu, lub systemu i ustalenie, iż spełnia on wymagane wyniki.
Przyznasz, iż to trochę zawiła definicja. Poniżej przedstawiam Ci nieco prostszą, napisaną przez nieco bardziej przystępnego autora:
Myers, Glenford J
The art of software testing
w moim przekładzie:
Testowanie systemu to proces uruchomiania programu lub systemu w celu znalezienia błędów.
No i super. Wiemy już, czym jest testowanie oprogramowania. Zwróć tylko uwagę, iż nie powiedzieliśmy sobie jeszcze o żadnej automatyzacji. Lecimy zatem z kolejnym pytaniem:
Czym jest testowanie automatyczne?
Dustin, Elfriede; Rashka, Jeff; Paul, John
Automated Software Testing: Introduction
w moim przekładzie:
Zarządzanie i wykonywanie czynności testowych, w tym tworzenie i wykonywanie skryptów testowych przy użyciu zautomatyzowanych narzędzi testowych.
Na podstawie tych cytatów, możemy więc skonstruować własną definicję, odpowiadając jednocześnie na pytanie:
Czym jest test automatyczny?
phphub.pl ( ͡° ͜ʖ ͡°)
Test automatyczny jest to skrypt uruchamiany przy pomocy zautomatyzowanych narzędzi, który realizuje określone czynności testowe mające na celu wykrycie potencjalnych błędów w aplikacji.No i na sam koniec takie oto pytańsko:
Czym jest regresja testów?
Thibault Béziers La Fosse, Jean-Marie Mottu, Massimo Tisi, Gerson Sunyé
Source-Code Level Regression Test Selection: the Model-Driven Way
ensures that code updates do not break the functionalities that have already been sucCessfully tested.” [4]
w moim przekładzie:
„Testowanie regresyjne (…) to istotny krok w cyklu życia oprogramowania. Gwarantuje, iż aktualizacje kodu nie psują funkcjonalności, które zostały już pomyślnie przetestowane.”
Na podstawie powyższych cytatów już sam/a pewnie zauważasz — możemy automatyzować testowanie systemu w sposób powtarzalny! o ile dalej nie widzisz konkretnych zalet, które za tym idą, poniżej przedstawiam Ci listę, której możesz użyć w celu przekonania siebie, swojego zespołu lub swojego managementu. Mi niejednokrotnie już się przydała w dyskusjach, czy warto czy nie warto ( ͡° ͜ʖ ͡°)…
Zalety testów automatycznych
- Jakość — jest to najważniejsza zaleta testów wynikająca, z samej ich definicji. Testy piszemy w celu sprawdzenia, czy w aplikacji występują błędy, wobec czego mając zautomatyzowany sposób na znalezienie błędów, w sposób bezpośredni wpływamy na jakość oprogramowania.
- Mniejszy koszt — wytwarzanie systemu wymaga jego testowania. Po implementacji nowych funkcjonalności często musimy sprawdzić, czy stare funkcjonalności również działają, a to wszystko wymaga czasu i wielokrotnego powtarzania testów, a to wszystko kosztuje. Mając zautomatyzowany sposób na powtarzanie testów (a więc regresji), oszczędzamy mnóstwo czasu, a więc pieniędzy.
- Pewność — testy zwiększają pewność zespołu deweloperskiego, zespołu QA, project managera, product ownera i klientów o tym, iż oprogramowanie działa tak, jak należy. Wpływa więc na mniejszy poziom stresu całego zespołu i zapewnia większą śmiałość przy implementacji nowych funkcjonalności oraz modyfikacji tych już istniejących.
- Lepsza architektura systemu, modułów — pisanie testów często wymusza pisanie kodu w sposób zgodny z dobrymi praktykami.
- Samodokumentujący się kod — pokrycie kodu testami, może być traktowane przez programistów jako dokumentacja, wyjaśniająca przewidziane przypadki i sposób prawidłowego (i nieprawidłowego) działania kodu.
- Pokrycie przypadków brzegowych — w trakcie pisania testu, programista często ma szansę uświadomić sobie, iż istnieją nieprzewidziane przez niego przypadki brzegowe, które muszą zostać obsłużone.
To tylko kilka tych, które wymyśliłem z tzw. „głowy”. pozostało wiele więcej…
Ale nie uprzedzajmy faktów ( ͡° ͜ʖ ͡°).
Podsumowanie
Podsumujmy sobie szybicutko, przez co dzisiaj przeszliśmy. Uzmysłowiliśmy sobie, z czym tak adekwatnie mierzy się developer, który walczy z projektem bez testów. Przebiliśmy się przez kilka starożytnych manuskryptów dotyczących testowania oprogramowania, w celu uspójnienia naszych definicji, o ile chodzi o testy automatyczne. Na tej podstawie wyciągnęliśmy wnioski, dlaczego faktycznie warto takie testy pisać.
W kolejnym poście z tej serii pokażę, jak ja identyfikuję typy testów. Postaramy się także wspólnie odpowiedzieć na pytanie, które z tych typów testów powinien pisać developer, a które tester automatyzujący.
A być może opowiem ci o tym, jakie są wady testowania systemu w sposób automatyczny
( ͡° ͜ʖ ͡°)? Daj znać, o czym wolał/abyś poczytać!
Do zobaczenia!
Źródła:
- [1] The Complete Guide to Software Testing, 2nd ed by Hetzel, William C. Publication info: Wellesley, Mass. : QED Information Sciences, 1988. ISBN: 0894352423
- [2] Myers, Glenford J., The art of software testing, Publication info: New York : Wiley, c1979. ISBN: 0471043281
- [3] Automated Software Testing: Introduction, Management, and Performance by Dustin, Elfriede; Rashka, Jeff; Paul, John
- [4] Source-Code Level Regression Test Selection: the Model-Driven Way Thibault Béziers La Fosse, Jean-Marie Mottu, Massimo Tisi, Gerson Suny
