Tworzenie integracyjnych środowisk testowych w całym przedsiębiorstwie jest powszechną, marnotrawną praktyką, która spowalnia wszystko i wszystkich. Środowiska te niezmiennie stają się cennym zasobem, który jest trudny do odtworzenia i stanowi wąskie gardło rozwoju. Zapewniają również fałszywe poczucie bezpieczeństwa ze względu na nieuniknione rozbieżności w danych i konfiguracji między środowiskami.
Brzmi ostro lub może także nawet znajomo? Ale właśnie w taki sposób duże środowiska integracyjne są określane w kolejnych wydaniach Technology Radaru Thoughtworks i to od 2017 roku! O rok dłużej, bo od 2016 raport ten sugeruje także wdrażanie testów kontraktowych jako jedno z możliwych rozwiązań tego problemu.
Temat samych testów kontraktowych pojawił się już w podkaście, w odcinku O testowaniu kontraktowym z Rafałem Maciakiem. W dzisiejszej rozmowie, wraz z Jackiem Milewskim, uzupełniamy to podejście o aspekty praktyczne, aby zabezpieczanie komunikacji pomiędzy serwisami nie stało się szybko długiem technicznym, którego utrzymanie będzie kosztować wszystkie zespoły czas i niepotrzebne nerwy.
Ostatecznie, kontrakt powinien zabezpieczać tylko i wyłącznie aspekty komunikacji między usługami, a nie weryfikować przykładowo działanie ich logiki walidacyjnej, biznesowej czy nawet procesowej, jak to niestety czasem bywa w projektach.
