Proč je téma důležité
V integračním prostředí může každá služba samostatně projít svými testy, a přesto společný proces selže. Stačí změnit název pole, typ hodnoty, povinnost atributu nebo chování chybové odpovědi. Kontraktní testování ověřuje, že poskytovatel a spotřebitel rozumějí rozhraní stejným způsobem.
Nejde o náhradu integračních nebo end-to-end testů. Jde o rychlou ochrannou vrstvu, která zachytí nekompatibilní změnu dříve, než se dostane do sdíleného prostředí.
Jak postupovat správně
Zmapujte poskytovatele a spotřebitele
U každého endpointu určete, kdo jej vlastní, kdo jej používá a jaký obchodní proces na něm závisí.
Popište očekávání konkrétními příklady
Zahrňte povinná pole, datové typy, význam stavových kódů a klíčové chybové scénáře. Příklady musí vycházet z reálného použití.
Testujte kontrakt u spotřebitele
Spotřebitel ověří, že dokáže pracovat s odpovědí odpovídající dohodnutému kontraktu bez potřeby živé služby.
Ověřujte kontrakty u poskytovatele
Poskytovatel v CI spustí všechny relevantní spotřebitelské kontrakty a zjistí, zda změna někoho nepoškodí.
Řiďte kompatibilitu a verze
Změny rozlišujte na kompatibilní a nekompatibilní. U breaking change připravte přechodné období, novou verzi nebo koordinovaný release.
Udržujte jasné vlastnictví
Kontrakt má vlastníka, pravidla aktualizace a viditelný stav. Neaktuální kontrakt je pouze falešná jistota.
Čemu se naopak vyhnout
- Příliš detailnímu kontraktu, který kopíruje interní strukturu a brání běžným změnám.
- Ověřování pouze úspěšné odpovědi bez chybových stavů a prázdných dat.
- Spoléhání na jedno sdílené integrační prostředí jako jediný důkaz kompatibility.
- Breaking changes bez identifikace všech spotřebitelů a přechodového plánu.
- Kontraktům bez vlastníka, které se při změně aplikace neaktualizují.
Praktický příklad
Marketingová platforma odesílá seznam kontaktů externímu poskytovateli. Spotřebitel očekává identifikátor, stav validace a seznam důvodů odmítnutí. Poskytovatel změní důvody z pole řetězců na objekty. Jednotkové testy obou služeb mohou projít, ale kontraktní test u poskytovatele změnu okamžitě označí jako nekompatibilní.
Tým má čas buď zachovat původní tvar, nebo vydat novou verzi endpointu a spotřebitele převést. Incident se tak řeší ještě před nasazením.
Ponaučení pro praxi
Kontraktní testování chrání dohodu mezi systémy. Nejlépe funguje, když je zaměřené na reálné potřeby spotřebitele, běží automaticky v CI a změny mají jasné vlastníky.
Správný postup nemusí být složitý. Důležité je, aby byl vědomý, opakovatelný a aby tým dokázal vysvětlit, proč zvolil právě tento způsob kontroly. Kvalita nevzniká jedním nástrojem ani jednou rolí; vzniká kombinací dobrých otázek, důkazů a následné zpětné vazby.