fbpx
Kubernetes Maestro → sprawdź najnowsze szkolenie »»

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.


.

Damian Naprawa

Software Architect, Docker Certified Associate, praktykujący entuzjasta konteneryzacji. Lubi dzielić się wiedzą na swoim blogu https://szkoladockera.pl oraz w podkaście "Więcej Niż Konteneryzacja". Uczestnik globalnego programu partnerskiego Docker Enablement. Od kilku lat używa kontenerów na produkcji oraz mówi w języku #docker & #kubernetes. Fan automatyzacji oraz podejścia "As a Code"

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *