:sparkles: PWA :sparkles:
Logo

Piotr Kowalski

Organizator WarsawJS , Trener, YouTuber

Definicje testów

Często spotykam się z niepoprawnym nazywaniem testów wykonywanych w procesie wytwarzania oprogramowania. Tym wpisem chciałbym przedstawić Ci sześć podstawowych typów testów. Mam nadzieje, że będziemy od teraz porozumiewać się tą samą terminologią (przynajmniej jeżeli chodzi o testy).

Testy w Inżynierii Oprogramowania

Testy jednostkowe (unit testing)

Testy stworzone przez autorów kodu, testują one pojedyncze metody, funkcje.

Bardzo lubię pisać testy jednostkowe, ponieważ po napisaniu ich dla danej metody, mam pewność poprawności jej działania. Podnosi to mój komfort podczas pracy twórczej (implementacji).

Narzędzia

Jakich narzędzi używam do pisania testów jednostkowych? Bardzo lubię składnie i idee, które są zaaplikowane w bibliotece Jasmine.

Pół roku temu stworzyłem na GitHubie projekt, gdzie wykorzystałem Jasmine oraz transpiler Babel - github.com/piecioshka/test-jasmine-babel. Niestety projekt ten nie zawiera większej definicji testów - nie ma punktu odniesienia. Jest on zrobiony tylko w celu udowodnienia (samemu sobie), że można wykorzystywać Babel.js aby tworzyć testy.

Projekt opisany poniżej już może bardziej zaciekawić.

Dobrym przykładem jest biblioteka github.com/piecioshka/super-event-emitter z większą ilością testów. Na dzień 2016-04-16 ich liczba wynosi 32. w katalogu test/unit/specs/, gdzie znajdują się pliki z definicją test case-ów, czyli przypadków, jakie są weryfikowane.

Ci z Was, którzy nie tworzyli wcześniej testów, to jest to najlepszy moment, aby w swoim projekcie (tak naprawdę w dowolnym) spróbować napisać kilka testów jednostkowych.

Pokrycie kodu (code coverage)

Podczas pisania testów jednostkowych ważne jest tzw. pokrycie kodu. Mam tutaj na myśli, stosunek procentowy, ile linijek kodu aplikacji zostało uruchomionych podczas testów. Jeśli coś zostało uruchomione, to tak jakby się przetestowało, jednak warto napisać kilka asercji to każdej konstrukcji, która coś modyfikuje.

Wskaźnik pokrycia kodu na poziomie 100%, mówi, że cały kod aplikacji został uruchomiony podczas testów. Ale proszę nie mylcie tego z tym, że każda linijka została przetestowana, bo tak nie jest!

Testy integracyjne (integration testing)

Testy stworzone przez developerów. Testują one procesy biznesowe w sposób emulujący zachowanie użytkownika. Zweryfikowane są połączenia między modułami.

Testy integracyjne to trudniejszy temat. Tutaj pojawia się stworzenie sztucznego (laboratoryjnego) środowiska, gdzie takie testy można uruchomić.

Narzędzia

Ostatnio chętnie używam narzędzia Nightwatch.js. Korzystnym przykładem takich testów jest bardzo znany sposób nagrywania scenariusza, takiego jaki tester realizuje podczas swoich testów funkcjonalnych, a potem ich automatycznego odtwarzania.

Najpopularniejsze narzędzie to taki testów nosi nazwę Selenium, jednak wyżej wymienione przeze mnie narzędzia jest o wiele lepsze dla nas (developerów JavaScript-u) ponieważ definicja testów jest pisania w języku, który używamy na co dzień.

Testy funkcjonalne (black-box testing)

Testy przeprowadzane przez osoby z zewnątrz (nie autorów kodu).

Testy takie są wykonywane najczęściej przez testerów - osobny dział weryfikujący poprawność działania aplikacji. Developer oddaje aplikację do testów uruchamiając ją na środowisku stagingowym, po to aby testerzy mogli ją "przeklikać".

Testy strukturalne (white-box testing)

Testy przeprowadzane przez osoby z zewnątrz tak, aby przetestować wszystkie przypadki kodu, przy tego rodzaju testach pomagają programiści, aby móc przetestować każdą linijkę.

Specjalny rodzaj testów funkcjonalnych, gdzie programiści modyfikują kod aplikacji, aby przetestować przypadki, które ciężko zreprodukować w środowisku uruchomionej aplikacji (na przykład modyfikacja czasu na urządzeniach takich jak telewizory).

Testy statyczne

Autorzy kodu, czytają kod źródłowy w poszukiwaniu błędów składni, ale też procesów biznesowych.

Takie testy realizowane są najczęściej podczas code review innego developera. Z mojego doświadczenia są to testy bardzo pomocne w zakończeniu zadania - na Twój kod patrzy cały zespół projektowy. Moje doświadczenie pokazuje, że warto spotkać się jako zespół i porozmawiać o konkretnej zmianie, przed wdrożeniem.

Jeśli realizujecie swoje projekty na GitHubie (albo GitLabie) to świetnie jest spotkać się zespołem na omawianiu danego Pull Request-u. Wszyscy skupiają się tylko na tej jednej zmianie (która może oczywiście dotyczyć wielu plików).

Testy dynamiczne

Porównywanie danych wyjściowych z oczekiwanymi.

Na analizowanym kodzie (w testach statycznych) dorzucamy testowanie kodu uruchamiając z przykładowymi danymi w oczekiwaniu na dane wyjściowe, które to powinny być zgodne z flow implementacji logiki biznesowej (albo algorytmu).

Podsumowanie

Wystarczy zapamiętanie tych 6 typów testów, wśród których najważniejsze są 3 pierwsze, a komunikacja w zespołach projektowych może się poprawić.

Zachęcam wszystkich, którzy jeszcze nie pisali testów jednostkowych albo integracyjnych do spróbowania. Możecie się wzorować na moich projektach:


1 miesiąc i 5 dni wcześniej napisałem: Moja przygoda z monadami w JavaScript 1 tydzień i 1 dzień później napisałem: WarsawJS Meetup #19

Możesz osadzić kod wykorzystując: <pre><code class="{language}"></code></pre>