Automatyzacja testów integracyjnych z użyciem dockera

Opublikowane przez admin w dniu

Cześć!

Dziś postaram się opowiedzieć trochę o automatyzacji testów integracyjnych przy pomocy dockera.

 

Według klasycznej piramidy testów, testy integracyjne powinny stanowić 20% wszystkich testów. Piramida ta jednak odnosiła się do aplikacji monolitycznych.

W przypadku rozproszonej aplikacji ilość testów integracyjnych powinna się zwiększać. Oczywiście, jak zwykle, to zależy od indywidualnej aplikacji. Większe skupienie na testach integracyjnych stosuje np. Spotify. Można o tym przeczytać tutaj. Spotify stosuje rozkład testów w postaci plastra miodu.

W skrócie:

  • Testy zintegrowane testują pełną integracje pomiędzy usługami. Są one ciężkie w konfiguracji, długotrwałe i kruche.
  • Testy integracyjne są bardziej wyizolowane i obejmują pojedynczą usługę. Dodatkowo, nadal wymagają sporo konfiguracji.
  • Testy szczegółów implementacji skupiają się na logice biznesowej w naszym serwisie.

W powyższym plastrze miodu brakuje mi jeszcze testów kontraktów, które mogą z powodzeniem jeszcze bardziej zredukować ilość testów typu integrated.

W .NET Core testy integracyjne są o wiele łatwiejsze w konfiguracji. Aplikacja bez problemu może być uruchamiana w pamięci. Wystarczy w projekcie testowym zainstalować kilka paczek nugetowych.

  • Microsoft.AspNetCore.Mvc
  • Microsoft.AspNetCore.Mvc.Core
  • Microsoft.AspNetCore.Diagnostics
  • Microsoft.AspNetCore.TestHost
  • Microsoft.Extensions.Configuration.Json

Następnie w testowym projekcie następujący kawałek kodu będzie hostował naszą aplikacje w pamięci. Zwykle taka konfiguracja powinna być wystarczająca.

Jednak zwykle w testach integracyjnych potrzebujemy zewnętrznej infrastruktury. Na przykład bazę danych, gdy chcemy ją wypełnić danymi przed testem, czy szyny komunikatów, gdy chcemy sprawdzić, czy nas serwis opublikował jakąś wiadomość. Z automatyzacją tego procesu może nam pomóc docker i docker-compose.

Automatyzacja tego procesu (np. w procesie CI/CD) zawiera się w kilku krokach.

1. Stworzeniedockerfile dla projektu testowego, który mógłby wyglądać mniej więcej tak:

    2. Stworzenie pliku docker-compose w którym oprócz naszej infrastruktury musimy  zdefiniować health checki oraz poczekać, aż nasza infrastruktura będzie gotowa do uruchomienia testów.

    3. Na serwerze CI musimy teraz uruchomić naszego docker-compose oraz sczytać kod wyjścia. Możemy to zrobić w powershellu, czy innym języku skryptowym, którego używamy. Gdy testy się powiodą, nasza komenda powinna zwrócić kod wyjścia 0.  Na przykład w jenkinsie możemy użyć klauzuli try catch. Nasz skrypt w powershellu może wyglądać następująco:

    Parametr --renew-anon-volumes zapewni nam, że nasze wolumen będzie zawsze postawiony od zera. --build przebuduje nasze obrazy. Ma to zapobiec uruchomieniu starych/wcześniejszych testów. --no-start nie uruchomi naszych kontenerów. Zrobimy to w następnej komendzie run ponieważ jest w ten sposób łatwiej wyciągnąć kod wyjścia naszych testów. Na koniec usuwamy nasz kontener z testami.

     

    Powyższy plan działania z sukcesem zautomatyzuje nasz testy integracyjne. Jednak jest kilka mankamentów z tym rozwiązaniem. Po pierwsze, dla każdego projektu testów integracyjnych musimy tworzyć 2 pliki – dockerfile oraz docker-compose. W erze mikroserwisów tych projektów może być sporo. Po drugie, jeśli chcemy odpalić testy lokalnie, to najpierw musimy uruchomić jakimś narzędziem docker-compose , poczekać aż infrastruktura będzie gotowa, potem uruchomić testy i ewentualnie usunąć kontenery po zakończonych testach. Spełnienie tych kroków kłóci się trochę z ideą testów automatycznych. Więc…

    WaitForDocker

    Aby zautomatyzować powyższy proces napisałem bibliotekę, która to umożliwia. Jej algorytm przedstawia się następująco: 

    1. Sczytaj plik docker-compose

    2. Wydziel usługi i ich porty ze znacznika services

    3. Sprawdź, czy powyższe porty są już aktualnie zajęte

    4. Uruchom docker-compose

    5. Uruchom zdefiniowane health checki i czekaj, aż wszystkie zwrócą pozytywną odpowiedź. Jeśli któryś z nich nie powiódł się, rzuć wyjątek.

     

    Wszystkie powyższe operacje mają dosyć szczegółowe logowanie. Na ten moment dostępne health checki to TCP, HTTP oraz COMMAND. Domyślnie WaitForDocker użyje health checku typu TCP i sprawdzi, czy dany port jest otwarty.

    Przykładowe użycie WaitForDocker dla RabbitMQ może wyglądać tak:

    Domyślnie uruchomiona zostanie następującą komenda:

    Przebieg całego procesu zostanie zalogowany. Po uruchomieniu biblioteki na serwerze CI (w tym przypadku AppVeyor) dostajemy opis całego procesu: 

     

    Po uruchomieniu testów możemy zatrzymać nasze kontenery.

    Więcej o samej bibliotece można przeczytać tutaj.

    Podsumowanie

    Automatyzacja testów integracyjnych z użyciem dockera nie jest skomplikowana. Jednakże główną jej wadą jest to, że lokalnie chcemy uruchamiać nasze testy z poziomu Visual Studio. W tej sytuacji musimy uruchomić najpierw docker-composez naszą infrastrukturą, a dopiero potem testy. W przypadku WaitForDocker mamy wszystko w jednym miejscu. Poza tym, osobiście o wiele bardziej wolę pisać kod w C#, niż w yamlu.