Apskaitos API išankstinis gamybinis testavimo planas

Atsakymas 201 Created iš apskaitos API nepasako beveik nieko. Jis patvirtina tik tai, kad serveris atsakė. Jis nepatvirtina, kad egzistuoja lygiai viena sąskaita faktūra, kad debetai lygus kreditams, kad dokumento numeris buvo priskirtas vieną kartą arba kad pakartotinis užklausoje po nutrūkusio ryšio neįrašys antros kopijos. Dauguma gamybinės apskaitos dublikatų kyla būtent dėl šios spragos: pakeitimas buvo patvirtintas serveryje, o klientas liko su nežinomu rezultatu ir tyliai pakartojo užklausą su nauju raktu.

Šis planas skirtas komandoms, kurios vertina apskaitos API prieš integruodamos jį į realią buhalteriją. Jame daugiausia dėmesio skiriama klaidų elgsenai, o ne sėkmingiems scenarijams. Kiekvienoje toliau pateiktoje srityje nurodyta, ką testuoti, kokius teiginius (assertions) patikrinti ir kas laikoma sėkmingu rezultatu. Šiame kontekste diegimo pagrindas yra Nordlet, kurio API naudoja apribotus nešėjo raktus (scoped bearer keys), dešimtainių eilučių (decimal-string) sumas, idiopotencijos raktus (idempotency keys) ir pasirašytus pranešimus (webhooks). Tikslios galutinio taško (endpoint) sintaksės ir atsakymų sutarčių ieškokite API konvencijų ir Pradžios puslapiuose, o ne pasikliaukite prielaidomis.

Ką iš tikrųjų reiškia „išlaikytas testas“

Testas įrodo, kad apskaitos integracija yra saugi tik tada, kai ji patvirtina semantiką, o ne būsenos kodus. Kiekvienam scenarijui testų rinkinys turėtų patvirtinti:

• Verslo šalutinį poveikį: egzistuoja lygiai vienas klientas, sąskaita faktūra, didžiosios knygos (general ledger) įrašas, numerio priskyrimas arba mokėjimo būsenos virsmas.
• Apskaitos vientisumą: debetai lygūs kreditams, o piniginis tikslumas išlieka po serializavimo.
• Pakartotinį veikimą: pakartotinis bandymas grąžina pradinį rezultatą, o ne naują įrašą.
• Patvarumą: audito įrašai ir pranešimų įvykiai egzistuoja vos operacijai pasitvirtinus.
• Nesėkmes be šalutinio poveikio: atmestos užklausos nesunaudoja dokumentų numerių ir neįrašo jokių dalinių didžiosios knygos eilučių.
• Atkūrimą: laikina klaida gali būti pakartota be dubliavimo ar nuolatinio duomenų praradimo.

„Google“ API rekomendacijos nubrėžia aiškią ribą: saugu pakartoti tik tas operacijas, kurių pakartotinis vykdymas palieka tą pačią galutinę būseną, o API turėtų nurodyti, kurios operacijos yra idiopotentinės, o ne aklai kartoti kiekvieną nesėkmę.

Paruoškite vienkartinę, stebimą aplinką

Naudokite smėlio dėžės (sandbox) įmonę, o ne gamybinę buhalteriją. Nordlet smėlio dėžės įmonė naudoja tuos pačius modulius ir API elgseną kaip ir reali įmonė, tačiau yra pažymėta kaip testiniai duomenys, todėl ją saugu naudoti didelės apimties dublikatų ir klaidų testams. Ši žyma po sukūrimo yra nekeičiama, todėl vėliau realios buhalterijos negalima perklasifikuoti į testinius duomenis. Atminkite, kad smėlio dėžės naudojimas yra matuojamas ir apmokestinamas lygiai taip pat kaip ir realiame versle, todėl savo apimties testus derinkite prie kainodaros, kuria naudojatės.

Prieš rašydami bet kokį testą, pasiruoškite:

• Specialią smėlio dėžės įmonę su nustatymu isSandbox: true.
• Testinį API raktą, kurio galiojimo sritis apsiriboja tik testuojamais moduliais.
• Pranešimų gavėjo galutinį tašką (webhook endpoint) arba vietinį tunelį, kuris išsaugo neapdorotą užklausos turinį (raw body).
• Įkeltus (seeded) klientus, tiekėjus ir žinomą sąskaitų planą.
• Bent du apskaitos periodus: vieną atvirą, kitą užrakintą.
• Testinį laikrodį arba datos fiksatūrą (fixture), jei diegimas tai palaiko.
• Vietinę saugyklą, kurioje registruojamas kiekvienas užklausos bandymas, idiopotencijos raktas, atsakymo maiša (hash), pranešimo pristatymas ir suderinimo rezultatas.

Vykdydami dublikatų testus nenaudokite bendrų paruošiamųjų (staging) duomenų. Paklydęs klientas ar sąskaita faktūra iš ankstesnio paleidimo vėlesnius teiginius padaro dviprasmiškus.

Kiekvieno pakeitimo fiksatūra turėtų apimti metodą, galutinį tašką, pilną turinį, idiopotencijos raktą, rakto sritį, kliento koreliacijos ID, pradžios ir pabaigos laiko žymas, atsakymo būseną, antraštes, turinį, užklausos ID ir tai, ar ryšys nutrūko prieš gaunant atsakymą. Pinigams naudokite fiksuotas dešimtaines eilutes, pavyzdžiui, "75.0000". Nordlet pinigines vertes vaizduoja kaip dešimtaines eilutes su iki keturių skaitmenų po kablelio, o pavyzdinėje sąskaitoje faktūroje naudojama būtent ši forma.

Kita sąrankos dalis yra klaidų injekcija. Jūsų testavimo įranga turėtų gebėti: uždelsti atsakymą, nutraukti TCP ryšį po to, kai serveris gavo užklausą, grąžinti sintetinius 429/500/502/503/504 atsakymus, iš pranešimo gavėjo grąžinti ne 2xx kodą, pristatyti tą patį pranešimą du kartus, sukeisti įvykių eiliškumą vietomis, sugadinti vieną pranešimo turinio baitą, pakeisti idiopotencijos rakto turinį paliekant patį raktą, paleisti dvi identiškas užklausas vienu metu ir užrakinti periodą tarp sąrankos ir registravimo. Šie scenarijai yra vertingesni už šimtą sėkmingų pavyzdžių.

Užfiksuokite sutartį prieš rašydami pakartojimo logiką

Sugeneruokite arba atsisiųskite OpenAPI schemą ir palyginkite ją su savo klientu. Nordlet skelbia savo OpenAPI specifikaciją API žinyne ir generuoja tipizuotus SDK iš tos pačios specifikacijos, todėl schema pagrįsti testai lenkia ranka spėliojamus variantus.

Patikrinkite privalomus laukus ir tipus, dešimtainės eilutės laukus, datų ir laiko žymų formatus, leistinus veiksmus ir sritis, klaidos voko formą, pranešimų įvykių schemas, kurie pakeitimai priima idiopotencijos raktą ir kurie atsakymo laukai identifikuoja sukurto objekto tapatybę.

Sėkmės kriterijai. Klientas vietoje atmeta neteisingus krovinius (payloads), kur schema to neleidžia. Serverio atsakymai atitinka dokumentuotą schemą. Neteisingos dešimtainės trupmenos, blogos datos ir trūkumai privalomuose laukuose sukuria struktūrizuotas patvirtinimo klaidas. Deterministiškai nesėkmingai patvirtintai užklausai pakartotiniai bandymai neatliekami.

Klaidos režimas, kurį reikia pagauti. Klientas išanalizuoja "121.0000" į dvejetainį slankiojo kablelio skaičių ir vėliau serializuoja šiek tiek kitokią sumą. Sveikieji skaičiai praeina; PVM eilutės ir trupmeniniai kiekiai subyrės. Pinigus testuokite kaip eilutes nuo pradžios iki galo.

Autorizacija ir nuomininkų izoliacija

Skaitymui ir rašymui naudokite atskirus raktus. Tada išbandykite visą matricą: trūkstamas raktas, neteisingas raktas, galiojantis raktas su nepakankama modulio apimtimi, galiojantis raktas su tinkama apimtimi, kitai įmonei priklausantis raktas ir bandymas perskaityti objektą iš kitos įmonės.

Teiginiai:

• Trūkstami arba neteisingi prisijungimo duomenys grąžina 401.
• Galiojantis raktas neturint reikiamo leidimo grąžina 403.
• Jokio apskaitos šalutinio poveikio nei vienai nesėkmei nesukuriama.
• Sėkminga užklausa negali perskaityti ar pakeisti kitos įmonės įrašų.
• Saugumo klaidos niekada nėra pakartotinai bandomos automatiškai.

Sėkmės kriterijus. Po testų atliekamais nuskaitymais, o ne tik būsenos kodais, galite įrodyti tiek autorizacijos teisingumą, tiek nuomininkų izoliaciją.

Įrodykite vieną švarią operaciją

Paleiskite nedidelį, deterministinį srautą: sukurkite arba suraskite testinį klientą, sukurkite sąskaitą faktūrą su dešimtainės eilutės sumomis, išrašykite ją, perskaitykite sąskaitą faktūrą ir jos apskaitos poveikį, perskaitykite audito įrašą ir gaukite pranešimą. Nordlet pradžios pavyzdys rodo, kad sąskaitos faktūros išrašymas priskiria nepertraukiamą numerį, patikrina, ar periodas atviras, ir toje pačioje operacijoje įregistruoja subalansuotą didžiosios knygos įrašą.

Patvirtinkite, kad sąskaita faktūra pasiekia numatytą būseną, dokumento numeris priskiriamas lygiai vieną kartą, debetai lygūs kreditams, PVM ir eilutės sumos sutampa su numatytuoju pusapvalio apvalinimo (half-up calculation) skaičiavimu, audito įraše nurodomas vykdytojas bei pakeitimas, pranešimas galiausiai pristatomas, o API atsakymas ir pakartotinis nuskaitymas sutaria dėl sąskaitos faktūros ID ir būsenos.

Vienas skirtumas, kurį verta įsidėmėti: gautas pranešimas nėra įrodymas, kad pakeitimas buvo sėkmingai patvirtintas. API atsakymas kartu su pakartotiniu nuskaitymu yra pagrindiniai jūsų operacijos teiginiai. Pranešimas įrodo pranešimą grandinės apačioje (downstream), ir jis testuojamas atskirai.

Idiopotencija: toks pat raktas, toks pat turinys

Sugeneruokite vieną raktą vienai loginei verslo operacijai, o ne po vieną raktą kiekvienam tinklo bandymui. Išsiųskite pakeitimą su raktu K ir turiniu B, išsaugokite sukurto objekto ID, tada vėl išsiųskite lygiai tą pačią užklausą.

Patvirtinkite, kad antrasis atsakymas reiškia tą pačią operaciją, objekto ID yra identiškas ir egzistuoja vienas verslo objektas, vienas įrašas, vienas dokumento numeris, vienas finansinis poveikis. Pakartotinis atsakymas turėtų turėti dokumentuotą pakartojimo antraštę – Nordlet atveju x-idempotent-replay: true – o audito pėdsakas neturėtų rodyti antro pakeitimo.

Dvi saugojimo taisyklės keičia tai, ko jūsų pakartojimo cikle turėtų tikėtis, todėl išbandykite jas tiesiogiai: išsaugota 4xx klaida atkartojama kaip bet kuris kitas atsakymas, o 5xx klaida visai nesaugoma, todėl po serverio klaidos pakartotinis bandymas iš naujo vykdo operaciją, o ne atkartoja ją. Raktai taip pat turi galiojimo laiką (Nordlet atveju – po 24 valandų), o tai apriboja laiką, kiek galima atkartoti atsakymą.

Nordlet dokumentacijoje žadama, kad pridedant antraštę Idempotency-Key pakartotina užklausa neleidžia sukurti dublikato, o jos API konvencijos apibrėžia tikslią pakartojimo antraštę ir baitas į baitą atsakymo reikalavimą. Šis principas atitinka „Stripe“ paskelbtą modelį: raktas identifikuoja loginę operaciją, pakartojimai grąžina išsaugotą rezultatą, o raktas, panaudotas pakartotinai su skirtingais parametrais, yra atmetamas, o ne tyliai pakeičiamas.

Sėkmės kriterijus. Egzistuoja lygiai vienas finansinės būsenos virsmas, nesvarbu, kiek kartų klientas siunčia tą pačią užklausą pakartojimo lange.

Idiopotencija: toks pat raktas, pakeistas turinys

Išsiųskite pradinę užklausą su raktu K ir turiniu B1, tada antrąją užklausą su raktu K ir turiniu B2, kur bent viena suma, klientas, data arba eilutė skiriasi.

Numatytas rezultatas: užklausa atmetama su dokumentuota rakto pakartotinio naudojimo klaida – Nordlet grąžina 422 idempotency_key_reuse – pradinis įrašas lieka nepaliestas, neatsiranda joks antras įrašas, numeris ar audito pakeitimas, o klientas „netaiso“ situacijos sugeneruodamas naują raktą. Tylus B2 priėmimas padarytų pakartojimo raktus nesaugiais.

Konkuruojančios dubliuotos užklausos

Paleiskite dvi identiškas užklausas tuo pačiu raktu tą pačią akimirką. Priklausomai nuo dokumentuotos elgsenos, viena vykdoma, o kita gauna vykdomo konflikto pranešimą – Nordlet grąžina 409 idempotency_in_progress – arba abi galiausiai pamato tą patį rezultatą.

Patvirtinkite, kad abu skambučiai negali sukurti nepriklausomų finansinių padarinių, priskiriamas daugiausia vienas dokumento numeris, laikinas konfliktas pakartotinai bandomas tuo pačiu raktu, o ne nauju, galutinis išteklius yra pilnas ir perskaitomas, o idiopotencijos įrašas nelieka visam laikui įstrigęs.

Klaidos režimas. Pakartojimų biblioteka, kuri kiekvienam bandymui sukuria naują UUID, vieną loginę operaciją paverčia keliais nepriklausomais įrašais ir visiškai panaikina idiopotenciją.

Nežinomas rezultatas po nutrūkusio ryšio

Tai pati svarbiausia gamybinė simuliacija. Išsiųskite pakeitimą su raktu K, leiskite serveriui jį patvirtinti, nutraukite ryšį prieš gaunant atsakymą, užregistruokite rezultatą kaip nežinomą, tada bandykite dar kartą su tuo pačiu raktu K ir suderinkite perskaitydami išteklių bei audito duomenis.

Patvirtinkite, kad pakartotinis bandymas grąžina pradinį arba dokumentuotą pakartotą atsakymą, egzistuoja lygiai vienas finansinis šalutinis poveikis, klientas pažymi operaciją kaip baigtą tik po sėkmingo pakartojimo arba suderinimo nuskaitymo, ir joks naujas raktas nesugeneruojamas. Pabaigos laikas (timeout) nereiškia, kad „nieko neįvyko“. „Stripe“ apibūdina idiopotenciją tiksliai kaip apsaugą nuo ryšio klaidų, kai serveris galėjo apdoroti pakeitimą anksčiau, nei klientas spėjo gauti atsakymą.

Konservatyvi pakartojimų politika

Sprendimai dėl pakartojimų priklauso tiek nuo klaidos, tiek nuo to, ar operacija yra idiopotentinė, o ne tik nuo HTTP metodo.

Paprastai pakartojami, išlaikant tą patį raktą: ryšio nutrūkimas arba laiko pabaiga po idiopotentinio pakeitimo, 408, 429 paisant retry-after, ir 502/503/504. Dokumentuotas vykdomo veiksmo idiopotencijos atsakymas gali būti pakartotas po trumpo delsiklio.

Nepakartojami be suderinimo: 400/422 patvirtinimo klaidos, 401/403 autentifikavimo nesėkmės, 404 nerasta resursui, verslo 409 konfliktai, nesusiję su vykdomu raktu, pakeistas turinys esamam raktui ir periodo užrakto atmetimas.

Patvirtinkite ribotą eksponentinį delsą (backoff) su atsitiktine dedamąja (jitter), aiškius maksimalius bandymus ir praleistą laiką, išlaikytą retry-after greičio apribojimams, tą patį raktą vienos operacijos pakartojimuose, naują raktą kiekvienai naujai operacijai ir žurnalus, kurie atskiria pradinį bandymą nuo pakartojimų.

Atskirai išbandykite greičio apribojimo (rate limiting) veikimą. Perženkite dokumentuotą ribą – Nordlet pagal nutylėjimą leidžia 300 užklausų per minutę vienam API raktui, o kai kurie neautentifikuoti galutiniai taškai turi savo mažesnes ribas vienam adresui – tada patvirtinkite, kad serveris grąžina greičio apribojimo atsakymą, klientas analizuoja retry-after kaip pauzę, o ne klaidą, jis sustoja, o ne plaka užklausomis, o sulaikyto pakeitimo pakartojimas vėl naudoja pradinį raktą. Antraštės x-ratelimit-* praneša apie likusį biudžetą, o tai puikiai tinka išankstiniam patvirtinimui. Saugokite greičio apribojimų testus toliau nuo finansinių teiginių, nebent jūsų fiksatūra gali atskirti sulaikytą bandymą nuo įvykdyto.

Pranešimų parašo patvirtinimas

Sukurkite imtuvą, kuris išsaugo neapdorotus baitus. Kiekvienam įvykiui: užfiksuokite neapdorotą turinį (raw body), perskaitykite antraštę x-nordlet-signature, apskaičiuokite laukiamą HMAC-SHA256 su prenumeratos paslaptimi, palyginkite naudodami laiko atžvilgiu pastovią funkciją (constant-time function), išanalizuokite JSON tik po patvirtinimo, įrašykite pristatymą ir po patvaraus priėmimo greitai grąžinkite 2xx. Nordlet pasirašo HMAC virš neapdoroto turinio, išsiunčia jį kaip sha256=<hex> ir bando pristatyti iš naujo taikydamas eksponentinį uždelsimą. „Stripe“ pranešimų gairės pabrėžia būtinybę patvirtinti nemodifikuotą neapdorotą turinį naudojant laiko atžvilgiu pastovią lyginimą.

Atlikite neigiamus testus: teisingas turinys ir paslaptis, teisingas turinys su neteisinga paslaptimi, vieno baito turinio pakeitimas, iš naujo serializuotas JSON su pakeistais tarpais, trūkstama antraštė, sugadintas parašas, pakartotas senas pristatymas, jei schemoje yra laiko žyma, ir galiojantis parašas, pristatytas neteisingai prenumeratai.

Sėkmės kriterijus. Priimamas tik teisingas neapdorotas turinys ir paslaptis. Neteisingi parašai gauna ne 2xx kodą. Neteisingi kroviniai niekada nepatenka į apskaitos eilę. Paslaptys lieka už įprastų žurnalų ribų. Apdorojimo programa patvirtina tik po to, kai įvykis patvariai įrašomas.

Dubliuoti ir netvarkingi pranešimai

Pristatymo patikimumas yra atskira problema nuo API idiopotencijos, todėl imtuvas taip pat turi būti idiopotentinis. Pristatykite tą patį įvykį du kartus, pristatykite įvykį sale_invoice.paid prieš įvykį sale_invoice.issued, grąžinkite 500 po išsaugojimo, bet prieš atsakant, ir pakartokite įvykį, kurį vartotojas jau apdorojo.

Patvirtinkite, kad dubliuoti pristatymai nedubliuoja mokėjimų, būsenos pakeitimų ar didžiosios knygos veiksmų, kad dublikatų šalinimo raktas naudoja teikėjo pristatymo arba įvykio ID, kai toks yra (arba dokumentuotą sudėtinį raktą, bet niekada savavališką laiko žymą), kad netvarkingi įvykiai niekada neperrašo naujesnės būsenos senesne, kad vartotojas gali nuskaityti dabartinę būseną iš API, kai tvarkos neužtenka, ir kad nepavykę vartotojo bandymai keliauja per eilę arba nepasiekiamų laiškų kelią (dead-letter path). „Stripe“ aiškiai įspėja, kad pristatymo tvarka nėra garantuojama, ir rekomenduoja saugoti apdorotų įvykių ID.

Laikykite galutinį tašką lengvą: patvirtinkite formą, patikrinkite parašą, išsaugokite arba įdėkite į eilę, patvirtinkite, grąžinkite 2xx. Suderinimas ir pranešimai priklauso asynchronei eigai. Išbandykite tai priversdami vėlesnį darbą sustoti viršijant pristatymo laiko pabaigą; teisingas imtuvas vis tiek patvirtina po patvaraus įdėjimo į eilę.

Atviri ir užrakinti apskaitos periodai

Nordlet užtikrina periodų užrakinimą registravimo metu visuose rankiniuose žurnaluose, dokumentų srautuose ir importuose, todėl išbandykite šią kontrolę daugiau nei vienoje vietoje. Sukurkite lygiaverčius dokumentus, kurių data yra atvirame periode, užrakintame periode, riboje prieš pat užraktą, kito atviro periodo pirmąją dieną ir su galiojančia dokumento data, bet negaliojančia registravimo data, jei API atskiria šiuos du dalykus.

Užrakinto periodo atveju patvirtinkite, kad užklausa atmetama su dokumentuota periodo užrakto klaida – Nordlet atveju tai 409 conflict – ir kad juk nėra rašomos didžiosios knygos eilutės, nenaudojamas dokumento numeris, dokumentas netampa įregistruotu ir nesuveikia sėkmės pranešimas. Atviro periodo versija turėtų būti sėkminga su tomis pačiomis finansinėmis vertėmis.

Lenktynių testas. Pradėkite registravimą atvirame periode, užrakinkite periodą užklausos viduryje ir patvirtinkite, kad įsipareigojimas (commit) negali apeiti užrakto. Kritinė sėkmės sąlyga: patvirtintas įrašas niekada nepateka į periodą, kuris buvo užrakintas prieš patvirtinant operaciją.

Audituojamumas ir suderinimas

Kiekvienam sėkmingam pakeitimui patvirtinkite, kad verslo objektas egzistuoja, apskaitos įrašas egzistuoja su debetais lygiais kreditams, audito įrašas egzistuoja, pranešimo įvykis egzistuoja arba yra pasiekiamas, o jūsų operacijos įrašas nurodo teikėjo objekto ID su pakartojimais, nurodančiais tą pačią loginę operaciją.

Kiekvienam atmestam pakeitimui patvirtinkite, kad nėra jokio dalinio dokumentas, numeris nebuvo sunaudotas, nebent sutartis leidžia rezervavimą, nėra didžiosios knygos įrašo, nėra sėkmės pranešimo ir klaida turi užklausos ID diagnozei nustatyti. Nordlet konvencijos aprašo pakeitimų audituojamumą ir subalansuotus registravimus kaip platformos garantijas, o balansą užtikrina atidėtas duomenų bazės trigeris įsipareigojimo metu, o ne vien programos kodas. Paverskite šias garantijas po testavimo atliekamomis suderinimo užklausomis, o ne pasitikėkite HTTP atsakymu.

Pagrindinė testų matrica

Sritis	Testavimo veiksmas	Numatytas teiginys	Sėkmės kriterijus
Autentifikavimas	Nėra rakto, neteisingas raktas, nepakankama apimtis	Struktūrizuotas 401/403; jokio šalutinio poveikio	Visi atmesti bandymai nesukuria jokio apskaitos įrašo
Schema ir pinigai	Neteisinga dešimtainė trupmena, data, privalomas laukas	Lygio patvirtinimo klaida	Nebandoma pakartoti ar atlikti dalinio įrašo
Įprastas registravimas	Sukurti ir išrašyti sąskaitą faktūrą atvirame periode	Vienas dokumentas, viena subalansuota didžioji knyga, vienas audito įrašas	Nuskaityta būsena ir didžioji knyga sutaria
To paties rakto pakartojimas	Pakartoti identišką pakeitimą, toks pat raktas ir turinys	Pradinis rezultatas atkartotas; jokių dublikatų	Objekto ID, numeris, žurnalo poveikis, auditas išlieka vienaskaitos
Pakeistas turinys, toks pat raktas	Pakartotinai naudoti raktą su kita suma	Dokumentuotas rakto pakartotinio naudojimo atmetimas	Pradinis įrašas nepaliestas; nieko naujo neįrašyta
Nutrūkęs ryšys	Įsipareigoti, nutraukti, pakartoti su tuo pačiu raktu	Atkartotas rezultatas	Lygiai vienas finansinis šalutinis poveikis
Užrakintas periodas	Įregistruoti dokumentą su data užrakintame periode	Periodo užrakto atmetimas	Nėra žurnalo, numerio, sėkmės pranešimo
Pranešimo parašas	Neteisinga paslaptis, pakeistas turinys	Ne 2xx iš imtuvo	Priimamas tik teisingas neapdorotas turinys ir paslaptis

Ką aš daryčiau pirmiausia

Jei laiko mažai, paleiskite testus ta tvarka, kuri pagauna brangiausias klaidas. Pradėkite nuo nutrūkusio ryšio pakartojimo, nes būtent šis vienintelis scenarijus sukuria daugumą realių dublikatų. Tada – to paties rakto ir pakeisto turinio idiopotencijos pora. Tada – užrakinti periodai, nes įrašas uždarytame mėnesyje yra audito problema, kuri pasirodo vėlai. Parašų tikrinimas ir netvarkingi pranešimai seka po to, o visa schema ir autorizacijos matrica gali būti nuolat vykdoma CI aplinkoje, kai tik klientas stabilizuojasi.

Visa kita šiame plane palaiko šiuos penkis dalykus. Sureguliuokite juos smėlio dėžės įmonėje, o suderinimo nuskaitymai tegu patvirtina šalutinius poveikius, ir jūs žinosite, kad integracija yra saugi, prieš jai paliečiant nors vieną realią knygą. Smėlio dėžės įmonę ir priskirtą testinį raktą galite sukurti per kelias minutes skiltyje Pradėti, o reikalingus modulius patikrinti funkcijų sąraše.

D.U.K.

Ar 2xx atsako pakanka norint patvirtinti, kad apskaitos įrašas pavyko?

Ne. Būsenos kodas patvirtina tik tai, kad serveris atsakė, o ne tai, kad egzistuoja lygiai vienas dokumentas, vienas numerio priskirimas ir vienas subalansuotas didžiosios knygos įrašas. Po kiekvieno pakeitimo testo turėtų sekti objekto, jo apskaitos poveikio ir audito įrašo nuskaitymas. Pavojingiausias atvejis yra priešinga kryptimi: operacija, kuri patvirtėjo, o klientas niekada negavo atsakymo.

Ar turėčiau sugeneruoti naują idiopotencijos raktą, kai užklausai baigiasi laikas (timeout)?

Ne, ir tai yra klaida, sukelianti daugumą gamybinių dublikatų. Raktas identifikuoja loginę verslo operaciją, o ne tinklo bandymą. Pakartokite tą patį raktą, tada suderinkite perskaitydami išteklių. Pakartojimų biblioteka, kuri kiekvienam bandymui sukuria naują UUID, vieną numatytą sąskaitą faktūrą paverčia keliais nepriklausomais įrašais.

Kas nutiks, jei iš naujo panaudosiu idiopotencijos raktą su kitu kroviniu (payload)?

Teisingas API jį atmeta, o ne tyliai pritaiko naują turinį. Nordlet grąžina 422 idempotency_key_reuse ir palieka pradinį įrašą nepaliestą. Jūsų klientas turėtų tai vertinti kaip programuotojo klaidą, kurią reikia ištaisyti, o ne kaip sąlygą, kurią galima apiti sugeneruojant naują raktą.

Ar pranešimai yra pakaitalas sukurto objekto nuskaitymui?

Ne. Pranešimo pristatymas įrodo pranešimą grandinės apačioje, o ne tai, kad operacija buvo atlikta taip, kaip tikėjotės, o pristatymo tvarka nėra garantuojama. Patvirtinkite parašą virš neapdoroto turinio, pašalinkite dublikatus pagal pristatymo arba įvykio ID ir paimkite dabartinę būseną iš API, kai vien įvykių tvarkos neužtenka nuspręsti, kas pasikeitė.

Kaip išbandyti registravimą į užrakintą apskaitos periodą?

Sukurkite lygiaverčius dokumentus atvirame ir užrakintame periode ir patvirtinkite, kad užrakintas atvejis yra atmetamas be didžiosios knygos eilučių, be sunaudotų dokumento numerių, be būsenos virsmo ir be sėkmės pranešimo. Tada paleiskite lenktynių versiją: pradėkite registravimą atvirame periode ir užrakinkite periodą užklausos viduryje. Patvirtintas įrašas niekada negali patekti į periodą, kuris buvo užrakintas prieš patvirtinant operaciją.

Ar galiu paleisti didelės apimties dublikatų testus smėlio dėžės įmonėje?

Taip. Smėlio dėžės įmonė elgiasi kaip reali, yra pažymėta kaip testiniai duomenys ir ištrinama nedelsiant, o ne po saugojimo lango, todėl tai yra tinkama vieta griaunantiems ir dubliavimo testams. Smėlio dėžės naudojimas vis tiek yra matuojamas ir apmokestinamas kaip reali naudojimas, todėl suplanuokite apimtis, o ne sukite ciklą neribotai.