Zamiast uruchamiać ciężką machinę testów integracyjnych, możemy gwałtownie i precyzyjnie zweryfikować, czy nasze API przez cały czas spełnia oczekiwania konsumentów – choćby jeżeli technologia po drugiej stronie jest zupełnie inna. W tym odcinku rozmawiamy o tym, jak wdrożyć to podejście, by uniknąć sytuacji, w której „za płotem pali się budynek sąsiada” z powodu jednej zmiany w kodzie.
Gościem tego odcinka jest Łukasz Reszke, konsultant i Software Engineer w firmie Arkency. Łukasz na co dzień zajmuje się ratowaniem systemów przed rozpadem oraz tchnięciem nowego życia w aplikacje legacy, głównie w ekosystemie Ruby on Rails. W swojej pracy łączy Domain Driven Design i Event Sourcing , ale jego drugą wielką inżynierską miłością – i głównym tematem naszej rozmowy – są testy kontraktowe.
Z tego odcinka dowiesz się:
- Czym testy kontraktowe różnią się od walidacji JSON Schema;
- Dlaczego w podejściu Consumer Driven to odbiorca danych dyktuje warunki, a nie dostawca;
- Kiedy wdrożenie Pact’a jest inwestycją, a kiedy zbędnym kosztem;
- Do czego służy Pact Broker i jak wykorzystać webhooki do automatyzacji procesu;
- Co to są pending contracts i jak zapobiegają blokowaniu wdrożeń przez nowe wymagania;
- Jakie są najczęstsze błędy przy projektowaniu testów kontraktowych;
- W jaki sposób LLM-y i AI wpływają na testy kontraktowe.
A teraz… PLAY!
Zasubskrybuj podcast (Spotify, Apple podcasts) lub ściągnij ten odcinek w mp3.
Linki:
- Pact;
- Pact Broker;
- Swagger;
- devtalk o nauce z pomocą LLM-ów;
- oraz devtalk o residuality z Andrzejem Krzywdą, również z Arkency.
Koniecznie zostaw komentarz: jak Ci się podoba odcinek?
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
.png)
