Docker Maestro → Dołącz już dziś! »»

Dzisiaj dla odmiany, zamiast formy tekstowej mam dla Ciebie wideo. Temat dosyć niszowy, ale warty uwagi, czyli Docker i testy jednostkowe. Oglądając to wideo, dowiesz się, dlaczego warto tworzyć testy jednostkowe dla obrazów oraz przede wszystkim nauczysz się jak to robić! Film skupia się głównie na praktyce, czyli na pisaniu testów i ich uruchamianiu.


Testy jednostkowe – po co to komu?

Tak samo jak tworzymy testy jednostkowe podczas programowania aplikacji, podobnie też, możemy tworzyć testy jednostkowe dla obrazów Dockera.

W przypadku pisania testów jednostkowych dla aplikacji, ich ideą jest sprawdzenie, czy pojedyncza funkcja większego systemu działa tak, jak sobie założyliśmy. Może to być zachowanie pojedynczej metody, czy też klasy. W momencie gdy dana funkcjonalność jest rozbudowana, testy pilnują tego czy całość działa poprawnie.

To tyle tytułem wstępu. Przechodzimy do konkretów.


Testy jednostkowe obrazów

W przypadku obrazów dockerowych, skupiamy się na testowaniu pojedynczych plików lub funkcjonalności znajdujących się w obrazie.

Dla przykładu możemy testować:

  • istnienie i zawartość plików
  • wartości zmiennych środowiskowych
  • poprawność działania narzędzi
  • dystrybucję systemu operacyjnego


Najpierw testy – później kontener

W przypadku „standardowych” testów jednostkowych (dla aplikacji), zasadą TDD (Test Driven Development) w bardzo ogólnym skrócie brzmi: „Najpierw testy – później kod”.

W naszym przypadku (Docker), możemy przełożyć to na następujące stwierdzenie: „Najpierw testy – później kontener”. Rozwijając ten skrót – najpierw tworzymy testy dla obrazu by upewnić się, że działa tak jak to sobie założyliśmy, a dopiero poźniej tworzymy kontener na podstawie tego obrazu.

Wydaje się proste? Zachęcam do oglądania oraz zasubskrybowania kanału!


Kiedy warto tworzyć testy jednostkowe dla obrazów?

Szczególnie poleciłbym tworzenie testów jednostkowych podczas pracy w zespole. Ze swojego doświadczenia wiem, że w większym zespole takie testy często weryfikują przypadkowe błędy. Przede wszystkim mam tutaj na myśli wszelkiego rodzaju literówki oraz błędy spowodowane nieznajomością wiedzy na temat tworzenia plików Dockerfile… 🙂

Innym powodem dla którego warto to robić, jest auto-dokumentacja naszych założeń. Przeglądając takie testy, możemy szybko przypomnieć sobie jakie były początkowe zamiary co do obrazu naszej aplikacji.

Przykładowo:

  • plik A powinien znajdować się w obrazie w katalogu X
  • plik A powinien mieć prawa dostępu 775
  • plik A powinien zawierać frazę o nazwie „ConnectionString”
  • framework niezbędny do działania naszej aplikacji powinien być w wersji X
  • w obrazie powinno znajdować się narzędzie curl
PS. Narzędzie, które wykorzystuję do tworzenia testów to Container Structure Test. Jest to kolejne narzędzie ze stajni Google’a.


Dołącz do newslettera

Już ponad 850 osób zapisało się na mój newsletter (zero spamu! - tylko informacje o nowych artykułach oraz ciekawe nowinki ze świata konteneryzacji).

Zapisując się, jako bonus prześlę Ci "21 Praktycznych Przykładów Użycia Dockera Dla Developerów" oraz zbiór "10 Najlepszych Praktyk Tworzenia Dockerfile"



Damian Naprawa

Praktykujący pasjonat konteneryzacji. Lubi dzielić się wiedzą, prowadząc warsztaty i szkolenia. Chętnie występuje również w roli prelegenta na meetupach i konferencjach. Uczestnik globalnego programu partnerskiego Docker Enablement. Pracuje z Dockerem na co dzień od kilku lat. Odpowiedzialny za tworzenie i utrzymanie systemów działających w oparciu o kontenery. Fan automatyzacji oraz podejścia "As a Code".

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *