Kiedy chcemy wprowadzić nową funkcję lub ulepszyć istniejącą, łatwo jest wpaść w pułapkę "to działa na moim komputerze": napisałeś jakiś kod, otworzyłeś odpowiednią stronę i zobaczyłeś, że działa. Można by pomyśleć, że to wszystko, czego potrzebujemy, ale posiadanie działającej funkcji to tylko niewielka część faktycznego ukończenia tej funkcji.
Chcemy zachować spokój za każdym razem, gdy wypuszczamy funkcję i zapewnić pewien stopień pewności, że przypadkowo czegoś nie zepsujemy. Istnieją dwa główne procesy, które temu zapobiegają: testowanie ręczne i testowanie automatyczne. Dokładnie wyjaśniamy nasz ręczny proces kontroli jakości w osobnym wpisie na blogu, więc tutaj zajmiemy się tylko automatycznymi częściami, ponieważ czasami po prostu potrzebujesz robotów zamiast ludzi ?!
Co rozumiemy przez zautomatyzowane testowanie?
Testy automatyczne są również kodem
Jeśli zmienimy coś na jednej stronie, nie powinno to nagle zepsuć innej strony. Gdybyśmy mieli testować każdą istniejącą funkcję za każdym razem, gdy wprowadzamy coś nowego, aby upewnić się, że nadal działa, nigdy nie bylibyśmy w stanie niczego wydać! Aby zapewnić pewien poziom bezpieczeństwa, stosujemy testy automatyczne. Koncepcja testów automatycznych nie jest niczym nowym i mamy nadzieję, że każda inna firma programistyczna również z nich korzysta! Pomyśleliśmy jednak, że warto byłoby wyjaśnić, dlaczego i w jaki sposób z nich korzystamy.
Testy automatyczne są uruchamiane za każdym razem, gdy zmienimy coś w kodzie. Co więcej, same testy również są kodem! Nawet jeśli funkcja działa, gdy testujemy ją ręcznie, nie jest kompletna, jeśli nie ma dla niej testu w kodzie. Fakt, że działa w tym momencie, w konkretnym przypadku testowym, na twoim komputerze, nie oznacza, że będzie działać w nieskończoność.
Uważamy, że testy są tak samo potrzebne jak sam kod, jeśli nie nieco bardziej. Dają nam jasną definicję tego, co nasz kod powinien robić i automatycznie upewniają się, że tak jest! Możemy swobodnie wprowadzać zmiany w kodzie bez obawy, że coś się zepsuje. Jeśli testy przejdą pomyślnie, wszystko powinno działać zgodnie z oczekiwaniami!
Dlaczego używamy testów automatycznych?
Nasze zautomatyzowane testy pozwalają nam działać szybciej, nie psując niczego. Nasza ręczna kontrola jakości jest znacznie szybsza, ponieważ nie musimy, na przykład, próbować tworzyć egzaminów o wielu różnych nazwach. Wiemy z naszych zautomatyzowanych testów, że to po prostu działa, więc nie musimy próbować tego ponownie!
Zautomatyzowane testy pozwalają nam działać szybciej, nie psując rzeczy
Z tego powodu możemy również być o wiele bardziej dokładni, niż byłoby to rozsądne ręcznie. Możemy przetestować wszystkie możliwe działania, jakie może podjąć kod, nawet te, które zakładają, że część witryny nie działa. Oczywiście taka sytuacja nigdy nie powinna mieć miejsca, a ręczne testowanie byłoby uciążliwe. Możemy jednak po prostu udawać, że strona nie działa i sprawdzić, czy wszystko będzie działać zgodnie z oczekiwaniami dzięki naszym automatycznym testom!
Na marginesie: Wskaźniki nie mają znaczenia
Testy automatyczne zawsze wywołują debatę na temat tego, jak duże pokrycie testami jest potrzebne. Pokrycie jest miarą tego, jak duża część kodu jest faktycznie testowana przez testy, podaną w procentach. Pokrycie testów jest czymś, co można automatycznie śledzić, co sprawia, że bardzo łatwo jest zdecydować, że powinno być tak wysokie, jak to tylko możliwe. Jeśli mamy 100% pokrycie testami, nic nie powinno się przypadkowo zepsuć, prawda?
Cóż...
Powiedzmy, że mamy jakąś funkcję, której przekazujemy liczbę. Wykonuje ona bardzo złożone obliczenia, a następnie zwraca nam wynik. To, co moglibyśmy zrobić jako test, to wywołać funkcję, a następnie sprawdzić, czy wynik jest liczbą. Oczywiście nie jest to sensowny test dla tego kodu: nie mamy pojęcia, czy funkcja wykonuje prawidłowe obliczenia! Jednak ten test pozwoli nam osiągnąć 100% pokrycie testami: cały fragment kodu został pokryty, ale nie w sposób, który cokolwiek znaczy.
Metryki są miłą kulą u nogi, aby sprawdzić, czy nie robimy czegoś naprawdę dziwnego, i w rezultacie używamy ich. Metryki nie są jednak miarą pozwalającą upewnić się, że piszemy kod dobrej jakości!
Czy wszystko jest ważne?
Zawsze piszemy testy dla wszystkiego, ale rozróżniamy scenariusze
Wierzymy, że każda część Easy LMS jest niezbędna, ponieważ bez niej nie byłoby tak samo! Niestety, wciąż jesteśmy ograniczeni skończoną ilością czasu. Nie jest rozsądne testowanie wszystkiego. Zawsze musimy dokonać kompromisu, jak głęboko chcemy coś zautomatyzować. Zawsze piszemy testy dla wszystkiego, ale rozróżniamy scenariusze. W niektórych przypadkach wystarczą proste testy, o których wspomnieliśmy wcześniej, ale jeśli coś jest krytyczne, idziemy jeszcze dalej!
Ale co, jeśli coś ma krytyczne znaczenie?
Niektóre części systemu mają krytyczne znaczenie. Na przykład, jeśli nikt nie może się zalogować, nie można wiele zrobić z Easy LMS. Mimo że nasze testy sprawdzają kod logowania, nadal chcielibyśmy spróbować zalogować się za każdym razem przed wydaniem nowej funkcji. Przeprowadzenie tej walidacji ręcznie oznaczałoby, że musielibyśmy poświęcić kilka minut za każdym razem, gdy chcemy coś wydać. Oczywiście moglibyśmy to zrobić, ale im więcej rzeczy uznamy za konieczne, tym więcej minut musielibyśmy poświęcić. A to się sumuje. Na szczęście możemy pójść o krok dalej. Testy, o których wspomnieliśmy wcześniej, testują kod, ale mamy też testy akceptacyjne. Wchodzą one w interakcję z witryną w taki sam sposób, jak w przeglądarce, co pozwala nam zautomatyzować niektóre kroki kontroli jakości, które w przeciwnym razie musielibyśmy wykonać! Oznacza to, że możemy ich użyć do przetestowania całej funkcji od końca do końca. Wracając do naszego poprzedniego przykładu, nie musimy już logować się za każdym razem, aby upewnić się, że działa. Jeśli nie, test akceptacyjny zakończy się niepowodzeniem! Wszystkie te metody pomagają nam wyłapać wiele błędów, zanim dotrą do użytkownika, ale w końcu wszyscy jesteśmy ludźmi;
