Plán předprodukčních testů pro účetní API

Odpověď 201 Created z účetního API neříká téměř nic. Potvrzuje pouze to, že server odpověděl. Nepotvrzuje však, že existuje právě jedna faktura, že má dáti se rovná dal, že číslo dokumentu bylo přiděleno jednou, nebo že opakovaný pokus po přerušeném spojení nevytvoří druhou kopii. Většina duplicit v produkčním účetnictví pochází právě z této mezery: mutace se na serveru uložila, zatímco klient zůstal v nevědomí ohledně výsledku a potichu zkusil požadavek odeslat znovu s novým klíčem.

Tento plán je určen pro týmy, které vyhodnocují účetní API předtím, než jej propojí s reálným účetnictvím. Zaměřuje se na chybové stavy, nikoli na ideální průběh (happy path). Každá níže uvedená oblast popisuje, co testovat, co ověřovat a co se považuje za úspěšný výsledek (pass). Kontextem implementace je zde Nordlet, jehož API využívá tokeny s vymezenou platností (scoped bearer keys), peněžní částky jako řetězce s desetinnou čárkou (decimal-string amounts), idempotenční klíče a podepsané webhooks. Konkrétní syntaxi koncových bodů (endpointů) a strukturu odpovědí najdete v dokumentaci Konvence API a Začínáme, namísto spoléhání se na předpoklady.

Co „úspěch“ ve skutečnosti znamená

Test dokazuje bezpečné účetní propojení pouze tehdy, ověřuje-li sémantiku, nikoli stavové kódy. Pro každý scénář by testovací sada měla potvrdit:

• Obchodní vedlejší účinek: existuje právě jeden zákazník, faktura, účetní zápis, přidělené číslo nebo přechod stavu platby.
• Účetní integrita: má dáti se rovná dal a peněžní přesnost přežije serializaci.
• Chování při opakování (replay): nový pokus vrátí původní výsledek namísto nového záznamu.
• Odolnost (durability): auditní záznamy a události webhooku existují ihned po potvrzení operace.
• Selhání bez vedlejších účinků: zamítnuté požadavky nespotřebují žádná čísla dokumentů a nezapíší žádné částečné řádky hlavní knihy.
• Obnova: přechodnou chybu lze zopakovat bez duplikace nebo trvalé ztráty dat.

Pokyny pro API od Googlu vymezují tuto hranici jasně: k opakování jsou bezpečné pouze ty operace, jejichž opakované provedení zanechá stejný konečný stav, přičemž API by mělo jednoznačně určit, které operace jsou idempotentní, namísto naslepo opakovat každé selhání.

Nastavení izolovaného a sledovatelného prostředí

Použijte testovací (sandbox) společnost, nikoli produkční účetnictví. Sandboxová společnost v Nordletu využívá stejné moduly a chování API jako reálná firma a je označena jako testovací data, což umožňuje bezpečné provádění testů s vysokým objemem duplicit a chyb. Tento příznak je po vytvoření neměnný, takže reálné účetnictví nelze později dodatečně překlasifikovat na testovací data. Mějte na paměti, že používání sandboxu je měřeno a účtováno stejně jako provoz v reálné společnosti, proto dimenzujte objemové testy s ohledem na svůj ceník.

Před napsáním jakéhokoli testu si připravte:

• Vyhrazenou sandboxovou společnost s příznakem isSandbox: true.
• Testovací klíč API s oprávněními omezenými pouze na testované moduly.
• Koncový bod webhooku nebo lokální tunel (tunnel), který zachovává surové tělo požadavku (raw body).
• Předpřipravené zákazníky, dodavatele a známou účtovou osnovu.
• Minimálně dvě účetní období: jedno otevřené a jedno uzamčené.
• Testovací hodiny nebo fixaci data, pokud to implementace podporuje.
• Lokální úložiště zaznamenávající každý pokus o požadavek, idempotenční klíč, hash odpovědi, doručení webhooku a výsledek odsúhlasení.

Nespouštějte duplicitní testy nad sdílenými stagingovými daty. Zabloudilý zákazník nebo faktura z předchozího běhu činí následná ověření nejednoznačnými.

Vaše testovací fixture pro každou mutaci by měla zachycovat metodu, koncový bod, plné tělo požadavku, idempotenční klíč, rozsah platnosti klíče (scope), klientské ID koroelace, časová razítka zahájení a dokončení, stav odpovědi, hlavičky, tělo, ID požadavku a informaci o tom, zda před doručením odpovědi nedošlo k přerušení spojení. Pro peněžní částky používejte pevné desetinné řetězce jako "75.0000". Nordlet reprezentuje peněžní hodnoty jako desetinné řetězce až se čtyřmi desetinnými místy a tento formát používá i ve svém vzoru faktury.

Druhou polovinou přípravy je injektáž chyb (failure injection). Vaše testovací prostředí by mělo být schopné zpozdit odpověď, přerušit TCP spojení poté, co server přijal požadavek, vracet syntetické odpovědi 429/500/502/503/504, vracet chybový kód mimo řadu 2xx ze strany příjemce webhooku, doručit stejný webhook dvakrát, změnit pořadí událostí, poškodit jeden byte v těle webhooku, změnit datovou payload idempotenčního klíče při zachování stejného klíče, spustit dva identické požadavky současně a uzamknout období mezi přípravou a zaúčtováním. Tyto scénáře mají větší hodnotu než stovka příkladů ideálního průběhu.

Uzavření kontraktu před psaním logiky opakování

Vygenerujte nebo načtěte schéma OpenAPI a porovnejte jej se svým klientem. Nordlet publikuje svou specifikaci OpenAPI v API reference a ze stejné specifikace generuje i svá typovaná SDK, takže testy řízené schématem jsou spolehlivější než ruční odhady.

Ověřte povinná pole a typy, desetinné řetězcové položky, formáty dat a časových razítek, povolené akce a rozsahy oprávnění, tvar chybové obálky (error envelope), schémata událostí webhooků, které mutace akceptují idempotenční klíč a která pole odpovědi identifikují vytvořený objekt.

Kritéria úspěchu. Klient lokálně odmítá neplatné payloady tam, kde to schéma umožňuje. Odpovědi serveru odpovídají dokumentovanému schématu. Neplatná desetinná čísla, špatná data a chybějící povinná pole generují strukturované chyby ověření. Pro deterministická selhání ověření se nesmí pokoušet o opakování.

Chybový stav k zachycení. Klient parsuje "121.0000" do binárního desetinného čísla (float) a později serializuje mírně odlišnou částku. Celá čísla projdou, ale řádky DPH a částečná množství selžou. Testujte peněžní částky jako řetězce od začátku do konce.

Oprávnění a izolace nájemníků (tenants)

Pro čtení a zápis používejte oddělené klíče. Následně otestujte celou matici: chybějící klíč, neplatný klíč, platný klíč s nedostatečným rozsahem modulu, platný klíč se správným rozsahem, klíč patřící jiné společnosti a pokus o čtení objektu z jiné společnosti.

Ověření:

• Chybějící nebo neplatné přihlašovací údaje vrací 401.
• Platný klíč bez požadovaného oprávnění vrací 403.
• U žádného z těchto selhání nevznikne žádný účetní vedlejší účinek.
• Úspěšný požadavek nemůže číst ani mutovat záznamy jiné společnosti.
• Bezpečnostní chyby se nikdy neopakují automaticky.

Kritéria úspěchu. Správnost oprávnění i izolaci nájemníků můžete prokázat následným čtením po testu, nikoli pouze stavovými kódy.

Prokázání jedné čisté transakce

Spusťte malý, deterministický tok: vytvořte nebo vyhledejte testovacího zákazníka, vytvořte fakturu s peněžními částkami ve formě desetinných řetězců, vystavte ji, načtěte fakturu a její účetní dopad, načtěte auditní záznam a přijměte webhook. Příklad Začínáme (Getting Started) od Nordletu ukazuje, že vystavení faktury přiděluje číslo bez mezer, kontroluje otevřenost období a ve stejné transakci zaúčtuje vyrovnaný účetní zápis.

Ověřte, že faktura dosáhne očekávaného stavu, číslo dokumentu je přiděleno právě jednou, má dáti se rovná dal, DPH a celkové součty řádků odpovídají očekávanému zaokrouhlení nahoru (half-up), auditní záznam uvádí aktéra a provedenou změnu, webhook je nakonec doručen a odpověď API spolu s následným čtením se shodují na ID faktury a jejím stavu.

Za připomenutí stojí jeden důležitý rozdíl: doručení webhooku není důkazem toho, že se mutace úspěšně uložila. Odpověď API v kombinaci s následným načtením dat jsou vašimi primárními transakčními tvrzeními. Webhook dokazuje následnou notifikaci a testuje se samostatně.

Idempotence: stejný klíč, stejné tělo

Vygenerujte jeden klíč pro každou logickou obchodní operaci, nikoli jeden klíč pro každý pokus o síťovou komunikaci. Odešlete mutaci s klíčem K a tělem B, uložte vytvořené ID a poté odešlete úplně stejný požadavek znovu.

Ověřte, že druhá odpověď představuje stejnou operaci, ID objektu je totožné a existuje právě jeden obchodní objekt, jeden zápis, jedno číslo dokumentu a jeden finanční dopad. Zopakovaná odpověď by měla obsahovat dokumentovanou hlavičku opakování – v případě Nordletu jde o hlavičku x-idempotent-replay: true – a auditní stopa by neměla vykazovat žádnou druhou mutaci.

Pravidla úložiště mění to, co by vaše smyčka pro opakování měla očekávat, proto je otestujte přímo: uložená chyba 4xx se opakuje stejně jako jakákoli jiná odpověď, zatímco chyba 5xx se neuloží vůbec, takže nový pokus po chybě serveru provede operaci znovu namísto přehrání uložené odpovědi. Klíče mají také svou platnost, v Nordletu vyprší po 24 hodinách, což omezuje dobu, po kterou je opakování možné.

Dokumentace Nordletu slibuje, že přidání hlavičky Idempotency-Key zabrání tomu, aby opakovaný požadavek vytvořil duplicitní záznam, a konvence API definují přesnou hlavičku opakování a požadavek na shodu odpovědi bajt po bajtu. Tento princip odpovídá publikovanému modelu Stripe: klíč identifikuje logickou operaci, opakování vrací uložený výsledek a klíč použitý opakovaně s odlišnými parametry je odmítnut namísto tiché změny.

Kritéria úspěchu. Bez ohledu na to, kolikrát klient odešle stejný požadavek v rámci okna pro opakování, existuje právě jeden přechod finančního stavu.

Idempotence: stejný klíč, změněné tělo

Odešlete původní požadavek s klíčem K a tělem B1, a poté druhý požadavek s klíčem K a tělem B2, kde se alespoň jedna částka, zákazník, datum nebo řádek liší.

Očekávaný výsledek: požadavek je odmítnut s dokumentovanou chybou opětovného použití klíče – Nordlet vrací 422 idempotency_key_reuse – původní záznam zůstane nedotčen, nevznikne žádný druhý záznam, číslo ani auditní mutace a klient se nesnaží situaci „vyřešit“ vygenerováním nového klíče. Tiché přijetí B2 by učinilo klíče pro opakování nebezpečnými.

Souběžné duplicitní požadavky

Odešlete dva identické požadavky se stejným klíčem ve stejný okamžik. V závislosti na dokumentovaném chování jeden proběhne, zatímco druhý obdrží konflikt probíhající operace – Nordlet vrací 409 idempotency_in_progress – nebo oba nakonec obdrží stejný výsledek.

Ověřte, že obě volání nemohou vytvořit nezávislé finanční dopady, je přiděleno maximálně jedno číslo dokumentu, dočasný konflikt se opakuje se stejným klíčem namísto nového, finální zdroj je kompletní a čitelný a záznam idempotence nezůstane trvale zablokovaný.

Chybový stav. Knihovna pro opakování, která generuje čerstvé UUID pro každý pokus, mění jednu logickou operaci na několik nezávislých zápisů a zcela tak maří smysl idempotence.

Nejistý výsledek po přerušeném spojení

Toto je vůbec nejdůležitější produkční simulace. Odešlete mutaci s klíčem K, nechte server ji potvrdit, přerušte spojení před doručením odpovědi, zaznamenejte výsledek jako neznámý, poté proveďte nový pokus se stejným klíčem K a proveďte odsouhlasení (reconciliation) načtením zdroje a dat auditu.

Ověřte, že opakovaný pokus vrátí původní nebo dokumentovanou zopakovanou odpověď, existuje právě jeden finanční vedlejší účinek, klient označí operaci jako dokončenou až po úspěšném opakování nebo načtení pro odsouhlasení a není vygenerován žádný nový klíč. Časový limit (timeout) neznamená, že „se nic nestalo“. Stripe popisuje idempotenci přesně jako ochranu proti chybám spojení, kdy server mohl mutaci zpracovat dříve, než klient stihl přijmout odpověď.

Konzervativní politika opakování

Rozhodnutí o opakování závisí jak na chybě, tak na tom, zda je operace idempotentní, a nikoli pouze na metodě HTTP.

Obvykle opakovatelné při zachování stejného klíče: reset spojení nebo vypršení časového limitu po idempotentní mutaci, 408, 429 po zohlednění hlavičky retry-after a 502/503/504. Dokumentovanou odpověď o probíhající idempotenci lze opakovat po krátké prodlevě.

Neopakovatelné bez odsouhlasení: chyby ověření 400/422, selhání ověření 401/403, 404 pro chybějící zdroj, obchodní konflikty 409 nesouvisející s probíhajícím klíčem, změněný payload u existujícího klíče a odmítnutí kvůli uzamčení období.

Ověřte exponenciální ustupování (exponential backoff) s náhodnou odchylkou (jitter), explicitní maximální počet pokusů a uplynulý čas, dodržování retry-after pro limity rychlosti, zachování stejného klíče napříč opakováními jedné operace, nový klíč pro každou novou operaci a logy oddělující původní pokus od opakovaných.

Otestujte omezování rychlosti (rate limiting) samostatně. Překročte dokumentovaný práh – Nordlet ve výchozím nastavení umožňuje 300 požadavků za minutu na jeden klíč API, přičemž některé neautentizované koncové body mají vlastní nižší limity na adresu – a ověřte, že server vrací odpověď o překročení limitu, klient parsuje retry-after jako prodlevu namísto chyby, pozastaví činnost namísto zahlcování a opakovaný pokus o zregulovanou mutaci znovu použije původní klíč. Hlavičky x-ratelimit-* informují o zbývajícím kreditu, což lze využít pro předběžné ověření. Testy omezování rychlosti držte stranou od finančních tvrzení, pokud vaše testovací prostředí nedokáže rozlišit zregulovaný pokus od potvrzeného.

Ověření podpisu webhooku

Vytvořte příjemce, který zachovává surové bajty (raw bytes). Pro každou událost: zachyťte surové tělo, přečtěte hlavičku x-nordlet-signature, spočítejte očekávaný HMAC-SHA256 s tajným klíčem předplatného (subscription secret), porovnejte pomocí funkce odolné vůči časovým útokům (constant-time function), parsujte JSON až po ověření, zaznamenejte doručení a po trvalém přijetí vraťte rychlou odpověď 2xx. Nordlet podepisuje HMAC nad surovým tělem, odesílá jej jako sha256=<hex> a opakuje doručení s exponenciálním ustupováním. Pokyny pro webhooks od společnosti Stripe zdůrazňují nutnost ověřovat nemodifikované surové tělo pomocí porovnání v konstantním čase.

Spusťte negativní testy: správné tělo a tajný klíč, správné tělo s nesprávným tajným klíčem, změna jednoho bajtu těla, znovu serializovaný JSON s pozměněnými bílými znaky, chybějící hlavička, malformovaný podpis, přehrané staré doručení, pokud schéma obsahuje časové razítko, a platný podpis doručený na nesprávné předplatné.

Kritéria úspěchu. Akceptováno je pouze správné surové tělo a tajný klíč. Neplatné podpisy obdrží kód mimo řadu 2xx. Neplatné payloady nikdy nevstoupí do účetní fronty. Tajné klíče zůstávají mimo běžné logy. Obslužná rutina potvrdí přijetí až po trvalém zaznamenání události.

Duplicitní a neuspořádané webhooks

Spolehlivost doručení je odlišný problém než idempotence API a příjemce musí být rovněž idempotentní. Doručte stejnou událost dvakrát, doručte událost sale_invoice.paid před událostí sale_invoice.issued, vraťte kód 500 po uložení, ale před odesláním odpovědi, a přehrajte událost, kterou již spotřebitel zpracoval.

Ověřte, že duplicitní doručení neduplikují platby, změny stavu ani účetní operace, že klíč pro deduplikaci využívá ID doručení nebo události poskytovatele, pokud existuje (nebo dokumentovaný složený klíč, nikdy libovolné časové razítko), že události v nesprávném pořadí nikdy nepřepíší novější stav starším, že spotřebitel může načíst aktuální stav z API, když pořadí nestačí, a že selhání na straně spotřebitele procházejí frontou nebo cestou pro nedoručitelné zprávy (dead-letter path). Stripe výslovně varuje, že pořadí doručení není zaručeno, a doporučuje ukládat zpracovaná ID událostí.

Udržujte koncový bod v minimalistické podobě: ověřte tvar, ověřte podpis, uložte nebo zařaďte do fronty, potvrďte přijetí, vraťte 2xx. Odsouhlasení a notifikace patří do asynchronního zpracování. Otestujte to tak, že přinutíte následné zpracování pozastavit činnost za hranicí časového limitu doručení; správný příjemce přesto potvrdí přijetí po uložení do trvalé fronty.

Otevřená a uzamčená účetní období

Nordlet vynucuje uzamčení období v okamžiku zaúčtování napříč manuálními deníky, toky dokumentů a importy, proto tuto kontrolu otestujte na více než jednom místě. Vytvořte ekvivalentní dokumenty s datem v otevřeném období, v uzamčeném období, na hranici těsně před uzamčením, první den následujícího otevřeného období a s platným datem dokumentu, ale neplatným datem zaúčtování, pokud API obojí odděluje.

Pro případ uzamčeného období ověřte, že požadavek je odmítnut s dokumentovanou chybou uzamčení období – v Nordletu jde o 409 conflict – a že nejsou napsány žádné řádky deníku, není spotřebováno žádné číslo dokumentu, žádný dokument nepřejde do stavu zaúčtováno a neodesílá se žádný úspěšný webhook. Verze s otevřeným období by měla uspět se stejnými finančními hodnotami.

Test souběžnosti (race test). Spusťte zaúčtování do otevřeného období, uzamkněte období uprostřed probíhajícího požadavku a potvrďte, že uložení nemůže obejít zámek. Kritická podmínka úspěchu: zaúčtovaná položka nesmí nikdy skončit v období, které bylo uzamčeno předtím, než se transakce stihla potvrdit.

Auditovatelnost a odsouhlasení

Pro každou úspěšnou mutaci potvrďte, že existuje obchodní objekt, existuje účetní zápis, kde má dáti se rovná dal, existuje auditní záznam, existuje nebo je dohledatelná událost webhooku a váš záznam operace ukazuje na ID objektu poskytovatele, přičemž opakované pokusy odkazují na stejnou logickou operaci.

Pro každou zamítnutou mutaci potvrďte, že neexistuje žádný částečný dokument, nebylo spotřebováno žádné číslo, pokud to kontrakt neumožňuje rezervací, neexistuje žádný záznam v hlavní knize, neexistuje žádný úspěšný webhook a chyba nese ID požadavku pro diagnostiku. Konvence Nordletu popisují auditovatelnost mutací a vyrovnané zápisy jako záruky platformy, přičemž vyrovnanost vynucuje odložený databázový trigger v okamžiku potvrzení namísto pouhého aplikačního kódu. Převeďte tyto záruky na testovací dotazy pro odsouhlasení namísto slepého spoléhání se na odpověď HTTP.

Hlavní testovací matice

Oblast	Testovací akce	Očekávané tvrzení	Kritérium úspěchu
Autentizace	Chybějící klíč, neplatný klíč, nedostatečný rozsah	Strukturovaná chyba 401/403; žádný vedlejší účinek	Všechny zamítnuté pokusy nevytvoří žádný účetní záznam
Schéma a peníze	Neplatné desetinné číslo, datum, povinné pole	Chyba ověření na úrovni pole	Nedojde k žádnému opakování ani částečnému zápisu
Běžné zaúčtování	Vytvoření a vystavení faktury v otevřeném období	Jeden dokument, jeden vyrovnaný deník, jeden auditní záznam	Stav po zpětném načtení a hlavní kniha se shodují
Opakování se stejným klíčem	Zopakování identické mutace, stejný klíč a tělo	Původní výsledek přehrán; žádná duplikace	ID objektu, číslo, dopad do deníku a audit zůstávají unikátní
Změněné tělo, stejný klíč	Opětovné použití klíče s jinou částkou	Dokumentované odmítnutí kvůli použití klíče	Původní záznam nezměněn; nic nového nebylo zapsáno
Přerušené spojení	Potvrzení, přerušení, opakování se stejným klíčem	Zopakovaný výsledek	Právě jeden finanční vedlejší účinek
Uzamčené období	Zaúčtování dokumentu datovaného v uzamčeném období	Odmítnutí kvůli uzamčení období	Žádný deník, žádné číslo, žádný úspěšný webhook
Podpis webhooku	Nesprávný tajný klíč, pozměněné tělo	Kód mimo řadu 2xx od příjemce	Akceptováno pouze správné surové tělo a tajný klíč

Čím bych začal jako první

Pokud je času málo, spusťte testy v pořadí, které zachytí nejnákladnější chyby. Začněte opakováním po přerušeném spojení, protože právě tento jediný scénář generuje většinu reálných duplicit. Poté otestujte dvojici idempotence se stejným klíčem a se změněným tělem. Následují uzamčená období, protože zaúčtování v uzavřeném měsíci představuje auditní problém, který se projevuje se zpožděním. Ověření podpisů a webhooks v nesprávném pořadí přijdou na řadu vzápětí, přičemž úplná matice schémat a oprávnění může běžet nepřetržitě v CI, jakmile se klient ustálí.

Vše ostatní v tomto plánu slouží na podporu těchto pěti oblastí. Jakmile je úspěšně ověříte proti sandboxové společnosti a čtení pro odsouhlasení potvrdí vedlejší účinky, budete mít jistotu, že integrace je bezpečná, ještě než se dotkne jediného reálného účetnictví. Sandboxovou společnost a klíč s omezeným rozsahem si můžete vytvořit během několika minut v sekci Začínáme a potřebné moduly si zkontrolovat v seznamu funkcí.

FAQ

Je odpověď 2xx dostatečná k potvrzení, že účetní zápis proběhl úspěšně?

Ne. Stavový kód potvrzuje, že server odpověděl, nikoli to, že existuje právě jeden dokument, jedno přidělené číslo a jeden vyrovnaný účetní zápis. Každý test mutace by měl po odpovědi provést zpětné načtení objektu, jeho účetního dopadu a auditního záznamu. Nebezpečný případ představuje opačný směr: operace, která se uložila, zatímco klient odpověď vůbec neobdržel.

Mám vygenerovat nový idempotentní klíč, když vyprší časový limit požadavku?

Ne. Právě toto je chyba, která způsobuje většinu produkčních duplicit. Klíč identifikuje logickou obchodní operaci, nikoli pokus o síťovou komunikaci. Opakujte stejný klíč a poté proveďte odsouhlasení načtením zdroje. Knihovna pro opakování, která generuje čerstvé UUID pro každý pokus, mění zamýšlenou fakturu na několik nezávislých zápisů.

Co se stane, když znovu použiji idempotentní klíč s odlišným payloadem?

Správné API jej odmítne namísto tiché aplikace nového těla. Nordlet vrací 422 idempotency_key_reuse a ponechává původní záznam nedotčen. Váš klient by měl tuto situaci brát jako programátorskou chybu k opravě, nikoli jako stav, který je třeba obejít vygenerováním nového klíče.

Jsou webhooks náhradou za zpětné načtení vytvořeného objektu?

Ne. Doručení webhooku dokazuje následnou notifikaci, nikoli to, že transakce proběhla tak, jak očekáváte, a pořadí doručení není zaručeno. Ověřte podpis nad surovým tělem, proveďte deduplikaci podle ID doručení nebo události a načtěte aktuální stav z API kdykoli, kdy samotné pořadí událostí nestačí k rozhodnutí o tom, co se změnilo.

Jak otestuji zaúčtování do uzamčeného účetního období?

Vytvořte ekvivalentní dokumenty v otevřeném a v uzamčeném období a ověřte, že případ v uzamčeném období je odmítnut bez řádků deníku, bez spotřebovaného čísla dokumentu, bez přechodu stavu a bez úspěšného webhooku. Poté spusťte souběžnou variantu: zahajte zaúčtování do otevřeného období a uzamkněte období uprostřed probíhajícího požadavku. Zaúčtovaná položka nesmí nikdy skončit v období, které bylo uzamčeno dříve, než se transakce stihla potvrdit.

Mohu v sandboxové společnosti spouštět velkoobjemové duplicitní testy?

Ano. Sandboxová společnost se chová jako reálná firma, je označena jako testovací data a maže se okamžitě namísto čekání po uplynutí doby uchování, takže představuje správné místo pro destruktivní a duplicitní testy. Používání sandboxu je nicméně měřeno a účtováno jako reálný provoz, proto objem testů plánujte namísto nekonečného opakování ve smyčce.