Grāmatvedības API pirmsražošanas testēšanas plāns

Atbilde 201 Created no grāmatvedības API nepasaka praktiski neko. Tā tikai apstiprina, ka serveris ir sniedzis atbildi. Tā negarantē, ka pastāv tieši viens rēķins, ka debeti sakrīt ar kredītiem, ka dokumenta numurs ir piešķirts vienu reizi, vai ka atkārtots pieprasījums pēc pārtrauktiem savienojuma datiem neiegrāmidos otru kopu. Lielākā daļa ražošanas vides grāmatvedības dublikātu rodas tieši šīs nepilnības dēļ: serverī ir izpildīta datu izmaiņa, kamēr klients saņem nezināmu rezultātu un klusībā atkārto pieprasījumu ar jaunu atslēgu.

Šis plāns ir paredzēts komandām, kas izvērtē grāmatvedības API pirms tā integrēšanas reālajā grāmatvedībā. Tas koncentrējas uz kļūdu scenārijiem, nevis uz veiksmīgiem izpildes ceļiem (happy paths). Katrā tālāk norādītajā sadaļā ir aprakstīts, kas jātestē, kas jāpārbauda ar apgalvojumiem (assertions) un kas tiek uzskatīts par veiksmīgu izpildi. Šeit izmantotais ieviešanas konteksts ir Nordlet, kura API izmanto tvēruma (scoped) piekļuves atslēgas, decimāldaļu virkņu naudas summas, idempotences atslēgas un parakstītus tīmekļa āķus (webhooks). Lai iegūtu precīzu galapunktu sintaksi un atbilžu līgumus, skatiet API konvenciju un Darba sākšanas lapas, nevis paļaujieties uz pieņēmumiem.

Ko patiesībā nozīmē "testa iziešana"

Tests pierāda, ka grāmatvedības integrācija ir droša tikai tad, ja tas pārbauda semantiku, nevis statusa kodus. Katram scenārijam testu komplektam ir jāapstiprina:

• Biznesa blakusefekts: pastāv tieši viens klients, rēķins, žurnāla ieraksts, numura piešķīrums vai maksājuma pāreja.
• Grāmatvedības integritāte: debeti ir vienādi ar kredītiem, un monetārā precizitāte saglabājas pēc serializācijas.
• Atkārtotas izpildes (replay) uzvedība: atkārtots pieprasījums atgriež sākotnējo rezultātu, nevis jaunu ierakstu.
• Izturība (durability): audita ieraksti un tīmekļa āķa notikumi pastāv, tiklīdz operācija ir apstiprināta.
• Kļūdas bez blakusefektiem: noraidīti pieprasījumi nepatērē dokumentu numurus un neieraksta nepilnīgas virsgrāmatas rindas.
• Atkopšana: pagaidu kļūdu var atkārtot bez dublēšanās vai neatgriezeniska zuduma.

Google API vadlīnijas novelk skaidru robežu: droši ir atkārtot tikai tās operācijas, kuru atkārtota izpilde atstāj identisku galējo stāvokli, un API ir jānorāda, kuras operācijas ir idempotentas, nevis akli jāatkārto katra kļūda.

Izveidojiet testēšanai paredzētu, novērojamu vidi

Izmantojiet smilškastes (sandbox) uzņēmumu, nevis produkcijas reālos datus. Nordlet smilškastes uzņēmums izmanto tos pašus moduļus un API uzvedību kā reāls uzņēmums, un tas ir marķēts kā testa dati, kas padara to drošu liela apjoma dublikātu un kļūdu testiem. Šo karodziņu pēc izveides nevar mainīt, tāpēc reālos grāmatvedības datus vēlāk nevar pārveidot par testa datiem. Ņemiet vērā, ka smilškastes lietojums tiek uzskaitīts un rēķināts tāpat kā lietojums reālā uzņēmumā, tāpēc pielāgojiet savu apjoma testu apjomus savam cenu plānam.

Pirms jebkura testa rakstīšanas sagatavojiet:

• Īpašu smilškastes uzņēmumu ar iestatījumu isSandbox: true.
• Testa API atslēgu, kas paredzēta tikai testējamajiem moduļiem.
• Tīmekļa āķa (webhook) galapunktu vai lokālo tuneli, kas saglabā sākotnējo pieprasījuma pamattekstu.
• Iesētus (seeded) klientus, piegādātājus un zināmu kontu plānu.
• Vismaz divus grāmatvedības periodus: vienu atvērtu, vienu slēgtu.
• Testa pulksteni vai datuma fiksatoru, ja to atbalsta ieviešana.
• Vietējo krātuvi, kas reģistrē katru pieprasījuma mēģinājumu, idempotences atslēgu, atbildes hašu, tīmekļa āķa piegādi un saskaņošanas rezultātu.

Neveiciet dubultus testus ar koplietotiem testa vides datiem. Nejauši izveidots klients vai rēķins no iepriekšējā testa padara turpmākos apgalvojumus neskaidrus.

Jūsu sagataves katrai datu izmaiņai ir jāfiksē metode, galapunkts, pilns pamatteksts, idempotences atslēga, atslēgas tvērums, klienta korelācijas ID, sākuma un beigu laika zīmogi, atbildes statuss, galvenes, pamatteksts, pieprasījuma ID un tas, vai savienojums tika pārtraukts pirms atbildes saņemšanas. Naudas summām izmantojiet fiksētas decimāldaļu virknes, piemēram, "75.0000". Nordlet attēlo naudas vērtības kā decimāldaļu virknes ar līdz pat četrām decimāldaļām, un tā rēķina piemērs izmanto tieši šo formātu.

Otra iestatīšanas daļa ir kļūdu ievade (failure injection). Jūsu testēšanas rīkam jāspēj aizkavēt atbildi, pārtraukt TCP savienojumu pēc tam, kad serveris ir saņēmis pieprasījumu, atgriezt sintētiskas 429/500/502/503/504 atbildes, atgriezt ne-2xx atbildi no tīmekļa āķa saņēmēja, piegādāt to pašu tīmekļa āķi divas reizes, mainīt notikumu secību, sabojāt vienu tīmekļa āķa pamatteksta baitu, mainīt idempotences atslēgas datu kopu, saglabājot pašu atslēgu, palaist divus identiskus pieprasījumus vienlaikus un bloķēt periodu starp iestatīšanu un iegrāmatošanu. Šie scenāriji ir vairāk vērti nekā simts veiksmīgu piemēru.

Nostipriniet līgumu pirms atkārtotu mēģinājumu loģikas izveides

Ģenerējiet vai iegūstiet OpenAPI shēmu un salīdziniet to ar savu klientu. Nordlet publicē savu OpenAPI specifikāciju API references sadaļā un ģenerē savas tipizētās SDK no tās pašas specifikācijas, tāpēc shēmas vadīti testi ir pārāki par minējumiem.

Pārbaudiet obligātos laukus un tipus, decimāldaļu virkņu laukus, datumu un laika zīmogu formātus, atļautās darbības un tvērumus, kļūdas struktūras formu, tīmekļa āķa notikumu shēmas, kuras datu izmaiņas pieņem idempotences atslēgu un kuri atbilžu lauki identificē izveidoto objektu.

Izpildes kritēriji. Klients lokāli noraida nederīgas datu kopas, kuras shēma neļauj izmantot. Servera atbildes atbilst dokumentētajai shēmai. Nederīgas decimāldaļas, slikti datumi un trūkstoši obligātie lauki rada strukturētas validācijas kļūdas. Deterministiskas validācijas kļūdas gadījumā netiek veikti atkārtoti mēģinājumi.

Kļūdu veids, ko novērst. Klients parsē "121.0000" par bināro peldošā komata skaitli un vēlāk serializē nedaudz atšķirīgu summu. Veseli skaitļi iziet testu, bet PVN rindas un daļskaitļu daudzumi neiziet. Testējiet naudas summas kā virknes no sākuma līdz beigām.

Autentifikācija un īrnieku (tenant) izolācija

Izmantojiet atsevišķas atslēgas lasīšanai un rakstīšanai. Pēc tam testējiet visu matricu: trūkstoša atslēga, derīga atslēga ar nepietiekamu moduļa tvērumu, derīga atslēga ar pareizu tvērumu, atslēga, kas pieder citam uzņēmumam, un mēģinājums nolasīt objektu no cita uzņēmuma.

Apgalvojumi:

• Trūkstoši vai nederīgi piekļuves dati atgriež 401.
• Derīga atslēga bez nepieciešamās atļaujas atgriež 403.
• Nevienas kļūdas gadījumā netiek izveidots grāmatvedības blakusefekts.
• Veiksmīgs pieprasījums nevar nolasīt vai mainīt cita uzņēmuma ierakstus.
• Drošības kļūdas nekad netiek automātiski atkārtotas.

Izpildes kritērijs. Jūs varat pierādīt gan autorizācijas pareizību, gan īrnieku izolāciju ar lasīšanu pēc testa, nevis tikai ar statusa kodiem.

Pierādiet vienu tīru darījumu

Veiciet nelielu, deterministisku plūsmu: izveidojiet vai atrodiet testa klientu, izveidojiet rēķinu ar decimāldaļu virkņu summām, izsniedziet to, nolasiet rēķinu un tā grāmatvedības efektu, nolasiet audita ierakstu un saņemiet tīmekļa āķi. Nordlet darba sākšanas piemērs parāda rēķinu izsniešanu, kas piešķir nepārtrauktu numuru, pārbauda, vai periods ir atvērts, un tajā pašā darījumā iegrāmato sabalansētu žurnāla ierakstu.

Apstipriniet, ka rēķins sasniedz paredzēto stāvokli, dokumenta numurs tiek piešķirts tieši vienu reizi, debeti ir vieni un tie paši ar kredītiem, PVN un rindu kopsummas atbilst paredzētajam aritmētiskajam noapaļojumam uz augšu (half-up), audita ieraksts norāda iesaistīto personu un izmaiņas, tīmekļa āķis galu galā tiek piegādāts, un API atbilde kopā ar sekojošu nolasīšanu sakrīt attiecībā uz rēķina ID un stāvokli.

Viena atšķirība, ko ir vērts paturēt prātā: saņemtais tīmekļa āķis nav pierādījums tam, ka datu izmaiņa ir apstiprināta. API atbilde kopā ar nolasīšanu ir jūsu galvenie darījumu apgalvojumi. Tīmekļa āķis pierāda paziņošanu saistītajām sistēmām, un tas tiek testēts atsevišķi.

Idempotence: tā pati atslēga, tas pats pamatteksts

Ģenerējiet vienu atslēgu katrai loģiskajai biznesa operācijai, nevis vienu atslēgu katram tīkla mēģinājumam. Nosūtiet datu izmaiņu ar atslēgu K un pamattekstu B, saglabājiet izveidoto ID un pēc tam nosūtiet tieši to pašu pieprasījumu vēlreiz.

Apstipriniet, ka otrā atbildes reize atspoguļo to pašu operāciju, objekta ID ir identisks un pastāv viens biznesa objekts, viena iegrāmatojums, viens dokumenta numurs, viens finansiālais efekts. Atkārtotajai atbildei ir jāsatur dokumentētā atkārtotās izpildes galvene (Nordlet gadījumā – x-idempotent-replay: true), un audita žurnālam jāuzrāda, ka otrā datu izmaiņa nav notikusi.

Divi uzglabāšanas noteikumi maina to, ko jūsu atkārtotajam ciklam vajadzētu sagaidīt, tāpēc pārbaudiet tos tieši: saglabāta 4xx atbilde tiek atkārtota tāpat kā jebkura cita atbilde, savukārt 5xx netiek saglabāta vispār, tāpēc atkārtots mēģinājums pēc servera kļūdas atkārtoti izpilda operāciju, nevis atgriež iepriekšējo rezultātu. Atslēgām ir arī derīguma termiņš – Nordlet gadījumā pēc 24 stundām –, kas ierobežo laiku, kurā ir pieejama atkārtota izpilde.

Nordlet dokumentācija sola, ka Idempotency-Key galvenes pievienošana novērš atkārtota pieprasījuma dublikātu izveidi, un tās API konvencijas nosaka precīzu atkārtotās izpildes galveni un baita precizitātes atbildes prasību. Šis princips atbilst Stripe publicētajam modelim: atslēga identificē loģisko operāciju, atkārtoti pieprasījumi atgriež saglabāto rezultātu, un atslēga, kas tiek izmantota atkārtoti ar citiem parametriem, tiek noraidīta, nevis klusējot mainīta.

Izpildes kritērijs. Pastāv tieši viena finanšu stāvokļa maiņa neatkarīgi no tā, cik reizes klients nosūta to pašu pieprasījumu atkārtotas izpildes logā.

Idempotence: tā pati atslēga, mainīts pamatteksts

Nosūtiet sākotnējo pieprasījums ar atslēgu K un pamattekstu B1, pēc tam otro pieprasījumu ar atslēgu K un pamattekstu B2, kur vismaz viena summa, klients, datums vai rinda atšķiras.

Paredzētais rezultāts: pieprasījums tiek noraidīts ar dokumentēto atslēgas atkārtotas izmantošanas kļūdu (Nordlet atgriež 422 idempotency_key_reuse), oriģinālais ieraksts paliek neskarts, neparādās neviens otrs ieraksts, numurs vai audita izmaiņa, un klients to "nelabo", ģenerējot jaunu atslēgu. Klusējot pieņemot B2, atkārtotu mēģinājumu atslēgas kļūtu nedrošas.

Vienlaicīgi dubultie pieprasījumi

Izpildiet divus identiskus pieprasījumus ar to pašu atslēgu vienā un tajā pašā brīdī. Atkarībā no dokumentētās uzvedības viens izpildās, kamēr otrs saņem notiekoša procesa konfliktu (Nordlet atgriež 409 idempotency_in_progress), vai arī abi galu galā novēro to pašu rezultātu.

Apstipriniet, ka abi zvani nevar izveidot neatkarīgus finanšu efektus, tiek piešķirts ne vairāk kā viens dokumenta numurs, īslaicīgs konflikts tiek atkārtots ar to pašu atslēgu, nevis jaunu, galvenais resurss ir pilnīgs un nolasāms, un idempotences ieraksts nepaliek pastāvīgi iestrēdzis.

Kļūdas veids. Atkārtotu mēģinājumu bibliotēka, kas katram mēģinājumam ģenerē jaunu UUID, pārvērš vienu loģisku operāciju vairākos neatkarīgos ierakstos un pilnībā sabojā idempotenci.

Nenoteikts rezultāts pēc pārtraukta savienojuma

Šī ir pati svarīgākā ražošanas vides simulācija. Nosūtiet datu izmaiņu ar atslēgu K, ļaujiet serverim to apstiprināt, pārtrauciet savienojumu pirms atbildes saņemšanas, reģistrējiet rezultātu kā nezināmu, pēc tam atkārtojiet ar to pašu atslēgu K un saskaņojiet, nolasot resursu un audita datus.

Apstipriniet, ka atkārtots mēģinājums atgriež oriģinālo vai dokumentēto atkārtotās izpildes atbildi, pastāv tieši viens finanšu blakusefekts, klients atzīmē operāciju par pabeigtu tikai pēc veiksmīgas atkārtotas izpildes vai saskaņošanas nolasīšanas, un netiek ģenerēta jauna atslēga. Noilgums (timeout) nenozīmē, ka "nekas nenotika". Stripe precīziem vārdiem apraksta idempotenci kā aizsardzību pret savienojuma kļūdām, kad serveris varētu būt apstrādājis datu izmaiņu pirms klienta spējas saņemt atbildi.

Konservatīva atkārtotu mēģinājumu politika

Atkārtotu mēģinājumu lēmumi ir atkarīgi gan no kļūdas, gan no tā, vai operācija ir idempotenta, nevis tikai no HTTP metodes.

Parasti atkārtojama, saglabājot to pašu atslēgu: savienojuma atiestatīšana vai noilgums pēc idempotentas datu izmaiņas, 408, 429 pēc retry-after ievērošanas, un 502/503/504. Dokumentētu procesā esošu idempotences atbildi var atkārtot pēc īsas aizkaves.

Nav atkārtojama bez saskaņošanas: 400/422 validācijas kļūdas, 401/403 autentifikācijas kļūdas, 404 trūkstošam resursam, biznesa 409 konflikti, kas nav saistīti ar notiekošu atslēgu, mainīts pamatteksts esošai atslēgai un perioda bloķēšanas noraidījums.

Apstipriniet ierobežotu eksponenciālo nobīdi ar gadījuma nobīdi (jitter), skaidrus maksimālos mēģinājumus un pagājušo laiku, retry-after ievērošanu ātruma ierobežojumiem, vienas un tās pašas atslēgas saglabāšanu vienas operācijas atkārtotos mēģinājumos, jaunu atslēgu katrai jaunai operācijai un žurnālus, kas atdala sākotnējo mēģinājumu no atkārtotiem mēģinājumiem.

Testējiet ātruma ierobežošanu atsevišķi. Pārkāpiet dokumentēto slieksni – Nordlet pēc noklusējuma atļauj 300 pieprasījumus minūtē uz vienu API atslēgu, un dažiem neautentificētiem galapunktiem ir savi zemāki limiti uz vienu adresi –, pēc tam apstipriniet, ka serveris atgriež ātruma ierobežojuma atbildi, klients parsē retry-after kā aizkavi, nevis kļūdu, tas pauzē, nevis atkārtoti bombardē sistēmu, un ierobežotās datu izmaiņas atkārtots mēģinājums izmanto oriģinālo atslēgu. Galvenes x-ratelimit-* ziņo par atlikušo budžetu, kas ir labs priekšapstiprinājums. Turiet ātruma ierobežošanas testus atstatus no finanšu apgalvojumiem, ja vien jūsu sagatave nevar atšķirt ierobežotu mēģinājumu no apstiprināta mēģinājuma.

Tīmekļa āķa (webhook) paraksta pārbaude

Izveidojiet uztvērēju, kas saglabā neapstrādātos baitus (raw bytes). Katram notikumam: fiksējiet neapstrādāto pamattekstu, nolasiet galveni x-nordlet-signature, aprēķiniet paredzēto HMAC-SHA256 ar abonēšanas noslēumu, salīdziniet, izmantojot konstantā laika funkciju, parsējiet JSON tikai pēc pārbaudes, ierakstiet piegādi un atgrieziet ātru 2xx atbildi pēc izturīgas pieņemšanas. Nordlet paraksta HMAC virs neapstrādātā pamatteksta, nosūta to kā sha256=<hex> un atkārto piegādes ar eksponenciālo nobīdi. Stripe tīmekļa āķu vadlīnijas pastiprina nemodificēta neapstrādātā pamatteksta pārbaudi ar konstantā laika salīdzinājumu.

Veiciet negatīvos testus: pareizs pamatteksts un noslēpums, pareizs pamatteksts ar nepareizu noslēpumu, par viena baita izmaiņām pamattekstā, atkārtoti serializēts JSON ar mainītām atstarpēm, trūkstoša galvene, kļūdains paraksts, atkārtoti piegādāts vecs pamatteksts, ja shēma ietver laika zīmogu, un derīgs paraksts, kas piegādāts nepareizajam abonementam.

Izpildes kritēriji. Tiek pieņemts tikai pareizs neapstrādāts pamatteksts un noslēpums. Nederīgi paraksti saņem ne-2xx atbildi. Nederīgas datu kopas nekad nenokļūst grāmatvedības rindā. Noslēpumi netiek iekļauti parastajos žurnālos. Apstrādātājs apstiprina saņemšanu tikai pēc tam, kad notikums ir izturīgi reģistrēts.

Dubultie un nepareizas secības tīmekļa āķi

Piegādes uzticamība ir atsevišķa problēma no API idempotences, un arī uztvērējam ir jābūt idempotentam. Piegādājiet to pašu notikumu divas reizes, piegādājiet notikumu sale_invoice.paid pirms notikuma sale_invoice.issued, atgrieziet 500 pēc datu saglabāšanas, bet pirms atbildes nosūtīšanas, un atkārtojiet notikumu, ko patērētājs jau ir apstrādājis.

Apstipriniet, ka dubultās piegādes nedubulto maksājumus, statusa izmaiņas vai žurnāla darbības, ka dublikātu novēršanas atslēga izmanto pakalpojumu sniedzēja piegādes vai notikuma ID, ja tāds pastāv (vai dokumentētu salikto atslēgu, nekad patvaļīgu laika zīmogu), ka nepareizas secības notikumi nekad nepārraksta jaunāku stāvokli ar vecāku, ka patērētājs var iegūt pašreizējo stāvokli no API, kad ar secību vien nepietiek, un ka neizdevušies patērētāja mēģinājumi tiek novirzīti pa rindu vai nederīgo ziņojumu (dead-letter) ceļu. Stripe skaidri brīdina, ka piegādes secība netiek garantēta, un iesaka saglabāt apstrādāto notikumu ID.

Uzturiet galapunktu vienkāršu: apstipriniet formu, pārbaudiet parakstu, saglabājiet vai ievietojiet rindā, apstipriniet, atgrieziet 2xx. Saskaņošana un paziņojumi pieder asinhronajai apstrādei. Testējiet to, liekot pakārtotajam darbam gulēt ilgāk par piegādes noilgumu; pareizs uztvērējs joprojām apstiprina saņemšanu pēc izturīgas rindu izveides.

Atvērti un slēgti grāmatvedības periodi

Nordlet ievieš periodu slēgumus grāmatošanas laikā manuālajos žurnālos, dokumentu plūsmās un importētos datos, tāpēc testējiet šo kontroli vairākās vietās. Izveidojiet līdzvērtīgus dokumentus ar datumu atvērtā periodā, slēgtā periodā, robežvērtībā tieši pirms slēguma, nākamā atvērtā perioda pirmajā dienā un ar derīgu dokumenta datumu, bet nederīgu grāmatošanas datumu, ja API atdala abus.

Slēgtā perioda gadījumā apstipriniet, ka pieprasījums tiek noraidīts ar dokumentēto perioda bloķēšanas kļūdu (Nordlet gadījumā – 409 conflict), ka netiek ierakstītas nekādas žurnāla rindas, netiek izmantots neviens dokumenta numurs, neviens dokuments nepāriet iegrāmatotajā stāvoklī un netiek aktivizēts veiksmes tīmekļa āķis. Atvērtā perioda versijai vajadzētu veiksmīgi noslēgties ar tām pašām finanšu vērtībām.

Sāncensības (race) tests. Sāciet iegrāmatošanu pret atvērtu periodu, bloķējiet periodu pieprasījuma vidū un apstipriniet, ka apstiprinājums nevar apiet slēgumu. Kritiskais izpildes nosacījums: apstiprināts grāmatojums nekad nenokļūst periodā, kas tika slēgts pirms darījuma apstiprināšanas.

Auditējamība un saskaņošana

Katrai veiksmīgai datu izmaiņai apstipriniet, ka biznesa objekts pastāv, grāmatvedības ieraksts pastāv ar debetiem, kas vienādi ar kredītiem, audita ieraksts pastāv, tīmekļa āķa notikums pastāv vai ir iegūstams, un jūsu operācijas ieraksts norāda uz pakalpojumu sniedzēja objekta ID, un atkārtoti mēģinājumi atsaucas uz to pašu loģisko operāciju.

Katrai noraidītai datu izmaiņai apstipriniet, ka nepastāv daļējs dokuments, nav patērēts neviens numurs, ja vien līgums neļauj rezervāciju, nepastāv neviens virsgrāmatas ieraksts, nepastāv veiksmes tīmekļa āķis, un kļūda satur pieprasījuma ID diagnostikai. Nordlet konvencijas apraksta datu izmaiņu auditējamību un sabalansētus grāmatojumus kā platformas garantijas, kur bilanci nodrošina atlikta datu bāzes trigeris apstiprināšanas brīdī, nevis tikai lietojumprogrammas kods. Pārvērtiet šīs garantijas par pēctesta saskaņošanas vaicājumiem, nevis uzticieties HTTP atbildei.

Galvenā testu matrica

Joma	Testa darbība	Paredzētais apgalvojums	Izpildes kritērijs
Autentifikācija	Nav atslēgas, nederīga atslēga, nepietiekams tvērums	Strukturēta 401/403; nav blakusefekta	Visi noraidītie mēģinājumi nerada grāmatvedības ierakstu
Shēma un nauda	Nederīga decimāldaļa, datums, obligātais lauks	Līmeņa validācijas kļūda	Nenotiek atkārtots mēģinājums vai daļējs ieraksts
Normāls grāmatojums	Izveidot un izsniegt rēķinu atvērtā periodā	Viens dokuments, viens sabalansēts žurnāls, viens audita ieraksts	Nolasīšanas stāvoklis un virsgrāmata sakrīt
Tās pašas atslēgas atkārtota izpilde	Atkārtot identisku datu izmaiņu, tā pati atslēga un pamatteksts	Sākotnējais rezultāts atgriezts; nav dublikāta	Objekta ID, numurs, žurnāla efekts, audits paliek viens
Mainīts pamatteksts, tā pati atslēga	Izmantot atslēgu atkārtoti ar citu summu	Dokumentēts atslēgas atkārtotas izmantošanas noraidījums	Oriģinālais ieraksts nemainīts; nekas jauns nav ierakstīts
Pārtraukts savienojums	Apstiprināt, pārtraukt, atkārtot ar to pašu atslēgu	Atgriezts rezultāts	Tieši viens finanšu blakusefekts
Slēgts periods	Grāmatot dokumentu ar datumu slēgtā periodā	Perioda bloķēšanas noraidījums	Nav žurnāla, nav numura, nav veiksmes tīmekļa āķa
Tīmekļa āķa paraksts	Nepareizs noslēpums, mainīts pamatteksts	Ne-2xx no uztvērēja	Tiek pieņemts tikai pareizs neapstrādāts pamatteksts un noslēpums

Ko es darītu vispirms

Ja laika ir maz, veiciet testus tādā secībā, kas novērš visdārgākās kļūdas. Sāciet ar pārtrauktā savienojuma atkārtoto mēģinājumu, jo šis viens scenārijs rada lielāko daļu reālo dublikātu. Pēc tam tās pašas atslēgas un mainītā pamatteksta idempotences pāri. Tad slēgtos periodus, jo grāmatojums slēgtā mēnesī ir audita problēma, kas parādās novēloti. Parakstu pārbaude un nepareizas secības tīmekļa āķi seko nākamie, un pilna shēmas un autorizācijas matrica var darboties nepārtraukti CI vidē, kad klients stabilizējas.

Viss pārējais šajā plānā atbalsta šos piecus punktus. Panāciet, lai tie ir zaļi pret smilškastes uzņēmumu, un saskaņošanas nolasījumi apstiprina blakusefektus, un jūs zināsiet, ka integrācija ir droša, pirms tā pieskaras nevienai reālai virsgrāmatai. Jūs varat izveidot smilškastes uzņēmumu un tvēruma testa atslēgu dažu minūšu laikā no Darba sākšanas lapas, un pārbaudīt, kuri moduļi jums nepieciešami, pret funkciju sarakstu.

FAQ

Vai 2xx atbilde ir pietiekama, lai apstiprinātu, ka grāmatvedības ieraksts izdevās?

Nē. Statusa kods apstiprina, ka serveris ir atbildējis, bet negarantē, ka eksistē tieši viens dokuments, viena numura piešķire un viens sabalansēts žurnāla ieraksts. Katram datu izmaiņu testam pēc atbildes ir jāveic objekta nolasīšana, tā grāmatvedības efekta un audita ieraksta pārbaude. Bīstamais gadījums ir pretējais virziens: operācija, kas tika apstiprināta, kamēr klients vispār nesaņēma atbildi.

Vai man vajadzētu ģenerēt jaunu idempotences atslēgu, ja pieprasījumam iestājas noilgums?

Nē, un šī ir kļūda, kas rada lielāko daļu ražošanas vides dublikātu. Atslēga identificē loģisko biznesa operāciju, nevis tīkla mēģinājumu. Atkārtojiet to pašu atslēgu, pēc tam saskaņojiet, nolasot resursu. Atkārtotu mēģinājumu bibliotēka, kas katram mēģinājumam izveido jaunu UUID, pārvērš vienu paredzēto rēķinu vairākos neatkarīgos ierakstos.

Kas notiek, ja es izmantoju idempotences atslēgu atkārtoti ar citu datu kopu?

Pareizs API to noraida, nevis klusējot piemēro jauno pamattekstu. Nordlet atgriež 422 idempotency_key_reuse un atstāj oriģinālo ierakstu neskartu. Jūsu klientam tas jāuztver kā programmēšanas kļūda, kas jāizlabo, nevis kā apstāklis, ko apvedināt, ģenerējot jaunu atslēgu.

Vai tīmekļa āķi ir aizstājējs izveidotā objekta nolasīšanai?

Nē. Tīmekļa āķa piegāde pierāda lejup straumes paziņojumu, nevis to, ka darījums tika apstiprināts tā, kā jūs to gaidījāt, turklāt piegādes secība netiek garantēta. Pārbaudiet parakstu virs neapstrādātā pamatteksta, veiciet dublikātu novēršanu pēc piegādes vai notikuma ID un iegūstiet pašreizējo stāvokli no API ikreiz, kad ar notikumu secību vien nepietiek, lai izlemtu, kas mainījies.

Kā es varu testēt grāmatošanu slēgtā grāmatvedības periodā?

Izveidojiet līdzvērtīgus dokumentus atvērtā periodā un slēgtā periodā, un apstipriniet, ka slēgtais gadījums tiek noraidīts bez žurnāla rindām, bez patērēta dokumenta numura, bez stāvokļa maiņas un bez veiksmes tīmekļa āķa. Pēc tam palaidiet sāncensības versiju: sāciet iegrāmatošanu pret atvērtu periodu un bloķējiet periodu pieprasījuma vidū. Apstiprinātam grāmatojumam nekad nav jānokļūst periodā, kas tika slēgts pirms darījuma apstiprināšanas.

Vai es varu veikt liela apjoma dubultos testus smilškastes uzņēmumā?

Jā. Smilškastes uzņēmums darbojas kā īsts uzņēmums, tas ir marķēts kā testa dati un tiek dzēsts uzreiz, nevis pēc saglabāšanas loga, tāpēc tā ir īstā vieta destruktīviem un dubultiem testiem. Smilškastes lietojums joprojām tiek uzskaitīts un rēķināts kā reāls lietojums, tāpēc plānojiet apjomu, nevis veiciet bezgalīgus ciklus.