Co jest lepsze od jednej prezentacji Jacka na WJUGu?
DWIE PREZENTACJE JACKA NA WJUGU!
Jacek wraz z naszym Partnerem CircleK zabierze nas w świat testów w sposób pełniejszy, niż dotychczas mieliśmy okazję na naszych spotkaniach. Od planowania strategii testów aż do testów kontraktowych.
Zapraszamy gorąco!
UWAGA! To spotkanie odbędzie się w siedzibie naszego Partnera - CircleK
ul. Puławska 145 (obok metra Wilanowska)
15.10.2024 godzina 18:00
Agenda:
- 18.00 - 18.10 - introduction
- 18:10 - 19:00 - Jacek Milewski - "Testowanie kodu to bajka.
Strategia taka, że unit i integration"
- 19:10 - 20:00 - Jacek Milewski - "Testy Kontraktowe:
nie potrzebuję środowisk testowych"
- 20:00 - 21:00 - networking
Abstrakty:
"Testowanie kodu to bajka. Strategia taka, że unit i integration"
Aha... Bo widzisz... ja mówię o testach integracyjnych między modułami, a Ty - między komponentami" - Powiedzieli sobie po godzinnej dyskusji nad Code Review. Po kolejnej godzinie okaże się że integracja modułu i komponentu to zupełnie dwie różne bajki. Ale po kolei - najpierw niech dojdą do tego że nie rozumieją nawzajem czym jest 'moduł' a czym 'komponent'.
Czy naprawdę jest tak że możemy pisać jedynie testy jednostkowe, integracyjne i UI? No, to czym jest ten unit? A integracyjny - to co z czym zintegrowane? A dlaczego to nie unit, skoro też pisze się w jUnit? Pewnie Integracyjny to ten wolny, a unit to ten szybki? Dlaczego w zasadzie mówią aby rozdzielać Logikę Aplikacyjną od Logiki Domenowej skoro i tak obkładam to testem integracyjnym?
A w testach Systemu końcówkami są wejścia i wyjścia klasy, komponentu, modułu, mikroserwisu, kontraktów czy całego systemu? A to w ogóle mamy jakieś komponenty i moduły? I co zrobi tester? Dla bezpieczeństwa i okiełznania chaosu zduplikuje przypadki testowe. Po to by na wielgachnym systemie na siódmej stronie formularza spróbować wpisać imię o jeden znak za długie. Nie ma to jak drogi zestaw testów który jest stabilnie czerwony.
Aj... przestań już! Boli! Chaos!
Z tym testowaniem to już tak jest. jUnit jest prosty, AssertJ również, Mockito, nawet Spock. Do ogarnięcia tutorialem. I tak zostajemy sami z rozrzuconymi narzędziami. Ale jak to poskładać... sensownie... trzeba by przyjąć jedną ze strategii testowania. Czekaj... to można mieć strategię?! Nawet kilka?... To nie ma jednej słusznej piramidy?! Pokaż!
Pokażę! Ale wyjdźcie z ustalonych ram i przygotujcie się na coś nowego.
"Testy kontraktowe: Nie potrzebuję środowisk testowych"
Warning! Real conversation ahead!
Me: Hey, is the POST /products API deployed on prod already?
Them: yes
Me: Cool! Then I'll deploy my service too
...
Me: I get 404 on this new API on prod. why?
Them: aaah... I thought you mean PUT /products, not POST. No, POST is in Code Review now ¯_(ツ)_/¯
21st century.
Computers are taking control of the world because, as you've seen, they should.
I'm gonna show how to have this question answered automatically, by the machine. That has already verified if the API is on prod, and if it exactly meets the needs of consumers - was the contract already met, and can we check the integration with external API... locally on our machines, not on test, qa, prod envs.
Contract Testing - If I were asked what is the single most important thing that is missing after moving from monoliths to microservices, I'd choose Contract Testing. We lost it, because the code will always compile. The failure is visible after the deployment where both services are running and have to communicate.
I'll also show how to introduce Contract Testing in your company, also sharing my experiences after introducing Pact and Spring Cloud Contract: what are the caveats.
