w , ,

FajneFajne Dobre!Dobre! ŚwietnieŚwietnie Że co?Że co? WnerwWnerw

Testy integracyjne – najlepsze praktyki w 3 krokach

testy jednostkowe, testy integracyjne, testy end to end

W swoim poprzednim artykule Piramida, diament i trofeum – jak rozplanować testy automatyczne w aplikacji – opisałem odpowiedzialność dla każdego z poziomów testu automatycznych. Więc jeśli między innymi chcesz wiedzieć kiedy powinniśmy implementować testy integracyjne do odsyłam Cię właśnie do tej publikacji. W tym artykule pokażę Ci jak podejść do implementacji testów integracyjnych, wykorzystując przy tym najlepsze praktyki, które zdobyłem w swojej wieloletniej praktyce.

Ten artykuł bazuje na wideo kursie TestowanieAutomatyczne.pl, więc jeśli chcesz dodatkowo zobaczyć jak zaimplementować omawiane kroki to zachęcam Cię do zapoznania się z tym kursem 😉

1. Niezbędność profili tam, gdzie testy integracyjne

Bardzo ważnym elementem jest możliwość wykorzystania profili, które ułatwią Ci zarządzać różnymi środowiskami. Najczęściej definiuje się środowiska:

  • developerskie – które będzie służyło do twojej codziennej pracy nad rozwojem aplikacji
  • produkcyjne – takie, które dedykowane jest końcowemu użytkownikowi
  • testowe – środowisko pośrednie pomiędzy środowiskiem developerskim i produkcyjnym w ramach którego możesz dokonywać testów nie tylko automatycznych, ale też funkcjonalnych, penetracyjnych i wszystkich innych.

Oczywiście podział na środowiska zależy od Ciebie lub organizacji w której pracujesz. Możesz zdefiniować swój alternatywny set 🙂

Dlaczego posiadania profili w testach integracyjnych jest ważne?

Ponieważ testy integracyjne wychodzą poza struktury Twojej aplikacji i łączą się z bazą danych, lub innymi serwisami – odpowiednio wykonując na nich operacje. Nie chcemy więc, aby skrypty testowe dokonały zmian w produkcyjnej bazie danych lub kluczowej usłudze uruchomionej na produkcji. Dlatego na te potrzeby najlepiej jest zapewnić odseparowane środowiska.

2. Każde środowsko powinno wykorzstywać mieć tą samą konfigurację

Kiedy pracowałem jako konsultant to często widziałem, powielaną praktykę dotyczącą wykorzystywanie bazy danych H2 w środowisku testowym. Ponieważ jest ona lekka, szybka i łatwa we wdrożeniu.

Jednak niesie to za sobą dużą konsekwencję. Bazy danych różnią się między sobą dialektem. Często skrypty migracyjne, lub niektóre operacje mogą się nie powieść w przypadku stosowania różnych baz danych. Najlepszą praktyką jest zaplanowanie środowisk w taki sposób, aby były między sobą one jak najbardziej zbliżone względem konfiguracji:

  • technologicznej – te same wersje JDK/Node/Baz danych itp.
  • konfiguracje i parametry serwerowe – zbliżona ilość RAM, przydziału procesora
  • dane – zbiór danych testowych, odwzorowujących strukturę danych tworzonych przez Klienta (a nie jakieś „test1”, „dummy value”)

W większości przypadków jest to bardzo trudne i kosztowne do zorganizowania dlatego warto przemyśleć np. dodatkowe profil i środowisko jakim jest np. Stage, który jest wierną imitacją systemu produkcyjnego. Takie podejście ułatwi znalezienie potencjalnego problemu jeszcze zanim trafi on na produkcje.

3. Stosuj skrypty migracyjne

Ułatwią Ci one pracę w przypadku budowy scenariuszy testowych. Stosując wersjonowanie baz danych możesz zautomatyzować zakładanie i wypełnianie bazy danych danymi.

Samo to podejście jest stosowanie tylko w testach integracyjnych, ale również często stanowi niezbędny element w procesie tworzenia oprogramowania. Dlatego warto zapoznać się z rozwiązaniami takimi jak FlayWay lub Liquibase, które wyręczą Cię z dużej ilości prac jakie trzeba by było wykonać manualnie.

Narzędzia te również umożliwiają weryfikowanie poprawności skryptów – to znaczy, jeśli na środowisku testowym będzie pracował więcej niż jeden developer, to masz pewność, że Twoje skrypty migracyjnie nie zmienią skryptów migracyjnych innego developera, bo system kontroli wersji czuwa nad integralności danych. Co sprawia, że możliwość pracy wielu osób na tym samym środowisku może odbyć się bez przeszkód.

Testy integracyjne – podsumowanie

Wszystkie trzy kroki świetnie sprawdzają się w integracji z Contnous Integrantion. które cyklicznie zapewni budowę Twojego oprogramowania. Czasami stanowi to jedyną drogę na właściwe przetestowanie całego oprogramowania, gdyż postawienie całego środowiska na komputerze developera może być zbyt trudne ze względu na złożoność. Jeśli chcesz w praktyce nauczyć implementowania wszystkich 3 kroków opisanych w tym artykule to polecam Ci odwiedzić TestowanieAutomatyczne.pl.

Napisane przez Przemysław Bykowski

Aktywny programista i energiczny trener. Specjalizuje się w Spring Boot i uczę go w ramach AkademiaSpring.pl. Po godzinach udzielam się na YouTubach. Więcej o mnie.

Dodaj komentarz

Piramida, Diament i Trofeum – Jak Rozplanować Testy Automatyczne w Aplikacji

Spring - solidny start

Spring i Spring Boot – rzeczowy przewodnik