Testování integrací před nasazením do provozu

Většina integrací se testuje jednou objednávkou. Vývojář vytvoří testovací nákup, zkontroluje, že dorazil do ERP, a nasadí. Pak přijde první sobota s dvěma sty objednávkami, jedna z nich má slevový kupon na dopravu, druhá produkt bez EAN a třetí přijde dvakrát, protože se platební brána nedočkala odpovědi. A ERP je v pondělí plné chyb.

Integrace se nerozbíjí na šťastné cestě. Rozbíjí se na okrajových případech, výpadcích a duplicitách. V článku ukážeme, jak testujeme napojení e-shopu na ERP, platby, dopravce a dodavatele dřív, než ho uvidí zákazníci.

Proč integrace selhávají až v provozu

Testovací prostředí bývá čistší než realita. Má deset produktů se všemi vyplněnými poli, jednoho zákazníka a žádný souběh. V provozu je situace jiná:

• Data jsou špinavá. Produkty bez kódu, adresy s poznámkou v poli ulice, zahraniční PSČ, názvy s emoji.
• Věci se dějí současně. Dvě objednávky stejného posledního kusu, import skladu během nákupu.
• Partneři vypadávají. API dopravce neodpovídá, ERP je v noci v údržbě, platební brána pošle notifikaci s minutovým zpožděním.
• Zprávy chodí vícekrát. Platformy při chybě doručení webhook opakují, takže stejná událost může přijít dvakrát.
• Limity. Při zátěži integrace narazí na rate limit API a dostane odpověď 429.

Dobrý testovací plán proto neověřuje, že integrace funguje. Ověřuje, jak se chová, když nefunguje něco kolem ní.

Prostředí: kde testovat

Integraci nikdy nevyvíjíme a netestujeme proti ostrému e-shopu. Potřebujete prostředí, kde chyba nic nestojí. Možnosti se liší podle platformy (k 9/2026, podmínky ověřte u poskytovatele):

Pokud ERP nebo dopravce testovací prostředí nemá, domluvte se aspoň na testovací firmě nebo účtu, případně si odpovědi partnera nasimulujte. Proč mít staging vždy, rozebíráme v článku Testovací prostředí (staging): proč ho mít vždy.

Testovací data: realita, ne vzorníček

Deset hezkých produktů nic neodhalí. Testovací data připravujeme tak, aby obsahovala případy, které v provozu opravdu nastávají:

• produkty s variantami, bez EAN, s nulovou cenou, s dlouhým názvem,
• zákazníky se zahraniční adresou, firmou a DIČ, bez telefonu,
• objednávky se slevovým kódem, dárkem, dopravou zdarma, dobírkou, více sazbami DPH,
• storna, částečné vratky, změny objednávky po zaplacení,
• diakritiku a speciální znaky ve všech textových polích.

Ideální základ je anonymizovaný vzorek skutečných dat. Osobní údaje zákazníků na testovací prostředí v původní podobě nepatří.

Co testovat: scénáře krok za krokem

Pro každou integraci sepisujeme scénáře ve čtyřech skupinách:

1. Šťastná cesta. Běžná objednávka projde celým tokem: e-shop, platba, ERP, dopravce, faktura, e-mail zákazníkovi. Kontrolujeme každé pole, ne jen to, že záznam vznikl.
2. Okrajové případy. Všechny varianty z testovacích dat výše. Sleva rozpočítaná do položek, zaokrouhlení, doprava zdarma, nulová položka.
3. Chyby a výpadky. Partner vrátí chybu 500, neodpoví do časového limitu, vrátí 429. Integrace má chybu zalogovat, zkusit to znovu s odstupem a po několika pokusech upozornit člověka. Nesmí tiše zahodit data.
4. Duplicity a pořadí. Stejný webhook doručený dvakrát. Webhook „zaplaceno“ dorazí dřív než „vytvořeno“. Import spuštěný dvakrát za sebou. Výsledek musí být pořád stejný, tedy integrace musí být idempotentní.

K tomu patří test zátěže. Pošlete do integrace tolik objednávek, kolik čekáte v nejsilnější den roku, a sledujte, jestli nenarazí na limity REST API partnera. U Shoptetu je například limit 3 souběžných spojení na token (k 9/2026), takže paralelní zpracování musí být omezené.

Typy testů a kdo je dělá

Akceptační testy se často vynechávají, a je to chyba. Vývojář pozná, že faktura vznikla. Účetní pozná, že má špatnou řadu nebo středisko. Automatické testy patří do procesu nasazování, víc v článku CI/CD pro e-shop.

Nasazení: postupně a s cestou zpět

I dobře otestovaná integrace se nasazuje opatrně:

• Mimo špičku. Ne v pátek odpoledne a ne před Black Friday.
• Postupně. Nejdřív souběh se starým řešením nebo jen část objednávek, pak vše.
• S plánem návratu. Víte, jak integraci vypnout a vrátit starý stav, a kdo to udělá.
• S kontrolou po nasazení. Jedna skutečná objednávka se skutečnou platbou malou částkou a skutečnou zásilkou.
• S monitoringem od prvního dne. Chyby, fronty, počty zpracovaných záznamů. Víc v článku Monitoring integrací.

První týden po nasazení kontrolujte denně, jestli počty objednávek v e-shopu a v ERP sedí. Rozdíl i o jednu objednávku je signál, že některý scénář chybí.

Jak na to prakticky

Checklist před nasazením integrace do provozu:

• Běží integrace na testovacím prostředí, ne proti ostrým datům?
• Obsahují testovací data okrajové případy z vašeho reálného provozu?
• Otestovali jste výpadek partnera, chybu 500, timeout a 429?
• Je zpracování odolné proti duplicitním zprávám a jinému pořadí?
• Prošli jste zátěžový test na úrovni nejsilnějšího dne?
• Odsouhlasili výsledek lidé ze skladu a účetnictví?
• Máte plán návratu a monitoring od prvního dne?
• Jsou v provozu nasazené ostré klíče a v testu testovací, ne obráceně?

Pokud chystáte nové napojení nebo vám stávající integrace občas „něco ztratí“, ozvěte se. Při stavbě integrací testovací scénáře, testovací prostředí a monitoring připravujeme jako součást zakázky a u existujících napojení doplníme testy a opravy v rámci programování na míru. Rozsah a cenu připravíme po konzultaci.