Hejo,
W dzisiejszym poście chciałbym podzielić się przemyśleniami nt. automatów testowych. Chciałbym odpowiedzieć, dlaczego nie wszędzie automaty się sprawdzają, dlaczego rozwijają myślenie oraz dlaczego w większych projektach są bardzo opłacalne ekonomicznie.
Ja sam naukę automatyzacji rozpocząłem stosunkowo szybko, na własną rękę, czy to posilkujac sie tutorami, czy to ucząc się na własnych błędach, kierując się intuicją podczas tworzenia skryptów dla tamtejszych projektów. Można powiedzieć, iż uczyłem się pisać automaty podczas rozwiązywania tamtejszych aktualnych, komercyjnych projektów. Drugą sprawą był oczywiście fakt, iż tamte automaty z biegiem czasu trzeba było przepisać od nowa (albo chociaż bardzo dobrze zoptymalizować). Nie można jednak ująć faktu, iż najszybciej szlifuje/zdobywa się umiejętności podczas aktywnego rozwiązywania kolejnych problemów.
Pierwszą aplikacją, której strukturę w całości pokryłem (razem z napisaniem test case'ów etc.) była aplikacja mobilna na Androida, dla dużego i poważnego klienta, gdzie nasz zespół zajmował się wtedy jej wsparciem (aktywnym i szybkie wprowadzanie nowych i skomplikowanych funkcjonalności). Okay.. Jeszcze wcześniej zajmowałem się automatami dla Frontendu ale nie liczę tych pierwszych, udanych test case'ów ponieważ nie były one komercyjnym projektem.
Podczas pracy nad wyżej wspomnianym projektem szybko okazało się, że fajnie byłoby mieć skrypty, które same sprawdziłyby “całą” aplikację (przede wszystkim jej podstawowe, core'owe cechy, bez których apka nie pracowałaby prawidłowo) po każdym nowym buildzie, dzięki czemu zaoszczędziliśmy wiele czasu oraz nerwów, poprzez wyłapywanie nowo powstałych defektów ad-hoc.
Używałem już wtedy Elipsa (Mars Edition jeśli dobrze pamiętam) - do dzisiaj to moje ukochane IDE - razem z TestNG (chyba ten Framework preferuje bardziej, niźli jUnit), Selenium WD oraz Appium jako proxy dla emulatora z Android SDK. Moje wczesne doświadczenia były bardzo pozytywne, proces automatyzacji nie okazał się (na początku) AŻ tak trudny. Problemy zaczęły się, kiedy pokryć trzeba było struktury odpowiadające za bardziej złożone i wymagające mechanizmy czy funkcjonalności, niż te proste 'klikacze'. I to właśnie clue automatów, a raczej tego, dlaczego ich pisanie może być angażujące i po prostu fajne.
Dla mnie pisanie automatów to nie sztuka sama w sobie (tak słyszałem od jednego z deweloperów). To możliwość rozwiązywania ciekawych problemów, gdzie nie tylko musisz dobrze rozplanowany przez się tesc case przełożyć na język maszynowy, ale i dodatkowo poszczególne kroki musisz przecież dobrze rozplanować, przewidując wszystkie wyjątki, kombinacje i odskocznie od reguły, krok po kroku (stąd testowanie testów).
Takie testy możesz wzbogacić o nowe funkcjonalności. Z czasem postawilem na wieksza randomowość danych wejściowych, pokrywałem zależnosci pomiedzy nimi, a danymi wyjściowymi, sprawdzałem algorytmy po UI, ostatecznie bawiąc się w programistę-amatora, gdzie za pomocą Aplikacji, którą sprawdzam tworzę jednocześnie osobne algorytmy, testując je w pamięci komputera. Wiem, że brzmi to skomplikowanie ale jeśli posiadasz już techniczne doświadczenie to bez problemu to zrozumiesz. O, doczepiłem do testów również automatycznie generowane screenshoty przy wykryciu błędu oraz automatyczne nagrywanie oraz zapisanie VIDEO dla egzekucji tychże. Może kiedyś opiszę dokładniej, na przykładzie na czym to polega (dla niecierpliwych - zapraszam na mojego Gita).
Wspominam o tym, ponieważ chcę pokazać, iz automatyk również jest programista (i tutaj pojawi się wielkie BUM! albo śmieszki kolejnego dewelopera), ponieważ dzięki pisaniu czystego i zrozumiałego kodu, dzięki wiedzy nt. używanych przezeń narzędzi oraz umiejętności pokrywania i egzekwowania kolejnych struktur/funkcjonalności kodu, dzięki intuicji i umiejętności uczenia się na “błędach” (dosłownie) oraz zupełnie innym sposobie myślenia, niźli programista stricte - automatyk na pewno nie ma się czego wstydzić.
W mojej opinii automaty są przede wszystkim dobre dla testów regresji stricte. Nie warto implementować ich, czy pokrywać struktur w projektach, które są nastawione na częste i szybkie zmiany. Polecałbym je przy budowaniu full-stockowych serwisów i pisanie już po UI, gdzie dla fajnego, poważnego frontendu mogą być nadal wprowadzane kolejne funkcjonalności na życzenie klienta. Podobnie sytuacja wygląda zresztą z apkami mobilnymi (praktycznie ze znaczną ich większością).
A co do samej ekonomii testów? Cóż. Na własnym przykładzie napiszę, iż kiedyś z czystej ciekawości obliczyłem stosunek manualnego przeklikania sprawdzenia funkcjonalności dla sklepu internetowego (formularze, koszyk zakupowy, drag&drop, iframe itd.). Znając dokładnie cały front end sprawdzenie manualne “zajęło” mi ponad 6 minut. Mojemu automatowi niecałe 21 sekund. I to razem z wygenerowaniem raportu dla 3 popularnych przeglądarek.
To by było na tyle w tym tygodniu,
Best,
bindy.
Brak komentarzy:
Prześlij komentarz