Batjocură și ciorapi pentru integrare

1) De ce avem nevoie de muguri și prize

• Izolați logica serviciilor dintr-un mediu instabil
• Determinați răspunsurile și erorile
• reproduce cazuri rare de frontieră (intervale de timp, 429/5xx, inconsecvență);
• rula teste locale și în CI rapid și previzibil.

2) Termeni și taxonomie

Stub este un ciot simplu cu un răspuns fix, fără verificări de interacțiune.
Mock - un obiect care așteaptă apeluri și le verifică (ordine/număr/argumente).
Fake este o implementare simplificată (de exemplu, un depozit In-Memory) cu un comportament real.
Spy este un ambalaj care înregistrează apeluri reale.
Service Virtualization este un serviciu extern „virtual” cu scripturi, caracteristici de stare și rețea.
Înregistrare/Replay - înregistrarea traficului real și redarea ulterioară (cu filtre/ediție).

3) Modele arhitecturale pentru testabilitate

Porturi și adaptoare (hexagonale): luați integrarea dincolo de interfețe - este ușor să o înlocuiți cu fals/simulator.
Strat anticorupție (ACL): un modul traduce un model extern într-un model de domeniu - mai puține puncte moka.
Clienți conștienți de contract: generarea OpenAPI/Protobuf → mai puține inconsecvențe manuale.
Caracteristică steaguri și moduri sandbox: securizate chei/endpoints pentru stabil furnizorului.

4) HTTP: instrumente și exemple

4. 1 WireMock (independent/Java DSL)

json
{
"request": { "method": "POST", "urlPath": "/v1/payouts", "headers": { "Idempotency-Key": { "matches": ".+" } } },
"response": {
"status": 201,
"headers": { "Content-Type": "application/json" },
"jsonBody": { "id": "po_123", "status": "queued" },
"fixedDelayMilliseconds": 80
}
}

java stubFor(post(urlEqualTo("/v1/payouts"))
.withHeader("Idempotency-Key", matching(".+"))
.withRequestBody(matchingJsonPath("$.amount", equalTo("100. 00")))
.willReturn(aResponse(). withStatus(201). withHeader("Content-Type","application/json")
.withBody("{\"id\":\"po_123\",\"status\":\"queued\"}")));

4. 2 MockServer (Dinamică/Verificări)

json
{
"httpRequest": { "method": "GET", "path": "/v1/wallets/w123" },
"httpResponse": { "statusCode": 200, "headers":[{"name":"Content-Type","values":["application/json"]}],
"body": { "id":"w123","currency":"EUR","balance":0 } }
}

4. 3 Hoverfly (middleware, înregistrare/reluare)

Înregistrați traficul împotriva cutiei de nisip a furnizorului, ștergeți PII-ul, fixați-l ca fixare.
În modul de simulare, adăugați variații: 200/4xx/5xx, întârzieri și ferestre „flaky”.

4. 4 Nod (Nock )/Python (răspunsuri )/Go ('httptest')

js nock('https://psp. example. com')
.post('/v1/payouts'). reply(201, { id:'po_123', status:'queued' })
.post('/v1/payouts'). reply (409, {code: 'duplicate'}) ;//second call - conflict

go srv:= httptest. NewServer(http. HandlerFunc(func(w http. ResponseWriter, r http. Request){
if r. Header. Get("Idempotency-Key") == "" { w. WriteHeader(400); return }
w. Header(). Set("Content-Type","application/json")
w. WriteHeader(201); w. Write([]byte(`{"id":"po_123","status":"queued"}`))
}))
defer srv. Close()

5) gRPC/Protobuf

5. 1 Generare înjunghiere

Generați un server prin '.proto', implementați metode cu răspunsuri controlate.
Verificați metadate (antete), stări ("coduri. Coduri InvalidArgument ','. DeadlineOvereded ').

go type FakePayouts struct{ pb. UnimplementedPayoutsServer }
func (f FakePayouts) Create(ctx context. Context, in pb. PayoutReq)(pb. PayoutRes,error){
if in. Amount <= 0 { return nil, status. Error(codes. InvalidArgument,"amount>0") }
return &pb. PayoutRes{Id:"po_123", Status:"QUEUED"}, nil
}

5. 2 grpcurl pentru negative

grpcurl -plaintext -d '{"amount":0}' localhost:50051 payouts. Payouts/Create

6) Posturi și fluxuri: Kafka/RabbitMQ

6. 1 Moki conștient de schemă

Utilizați Registrul Schema și validați Avro/JSON-Schema/Protobuf în teste.
Încercarea producătorului: mesajul corespunde schemei; Test de consum: acceptă versiuni vechi și noi.

6. 2 Testcontainere (exemplu Kafka + Registry)

java
KafkaContainer kafka = new KafkaContainer(DockerImageName. parse("confluentinc/cp-kafka:7. 6. 1"));
kafka. start();
//We publish the event and wait for consumption with deduplication by key

6. 3 Negative

Duplicate, rearanjarea comenzii, întârzierea livrării, mesaje „otrăvitoare” (scrisoare moartă).
Mesaje mari (aproape limită), versiuni de schemă nerecunoscute.

7) Prize conștiente de contract

7. 1 Pact (batjocuri CDC)

Consumatorul generează așteptări → pact fișier → furnizorul verifică pe stand.
Pact stub server joacă așteptările pentru testele de integrare client.

7. 2 OpenAPI/Protobuf → generație stabilă

Instrumente care ridică serverul mock din caietul de sarcini (inclusiv Prism, openapi-mock, grpc-mock).
Includeți exemple/coduri negative în caietul de sarcini: acesta este, de asemenea, un contract.

8) Rețea și haos: simularea eșecurilor

Întârzieri și jitter: fix/distribuit; verificați termenele limită și timpul de încercare.
Pauze: conexiuni pe jumătate deschise, RST, resetare flux H2, 503/Retry-After.
Pierderea pachetelor/duplicat: pentru gRPC/fluxuri.
Instrumente: Toxiproxy, MockServer (injecție de erori), xk6-disruptor, netem în CI.

toxiproxy-cli toxic add psp --type latency --latency 300 --jitter 100

9) Date, secrete și determinism

Redact și sintetice: fără PII în remedieri; bani - formatare zecimală/strictă.
Fixarea timpului: ceas fals; „ieri/azi” - control.
Idempotența: același „Idempotency-Key” → același răspuns.
Generatoare: fabrici/constructori de date cu valori transparente (de exemplu, „test _ user _ 001”).
Corecții de versionare (etichete), nu stocați răspunsuri „eliminate” fără mediere.

10) CI/CD și medii

Matrice: unitate (falsuri în proces) → componentă (virtualizare locală) → integrare (moks minime, Testcontainere).
Artefacte: fișiere pact, instantanee OpenAPI, jurnale de server ioc, PCAP pentru picături.
Paralelism: porturi unice/prefixe cheie; izolarea containerelor.
Poarta: contract verde (CDC verifica), caietul de sarcini valabil (scame), negative trecut.

11) Antipattern

Moki „copia” defecte în serviciul real → încredere falsă. Tratate cu contracte și periodice de înregistrare/verificare.
"Macromocks' din întreaga lume în fiecare test → fragilitate, costisitoare mainstream. Asigurați-porturi subțiri și ACL-uri.
Moki în E2E în care este necesară integrarea reală (în special plățile/cărțile web cu HMAC/mTLS).
Fulgi datorită timpului/aleatoriu/de curse de rețea → utiliza ceas fals, scaune deterministe.
Secrete în remedieri/depozite. Secretele - numai prin intermediul CI secret de stocare.

12) Specificul iGaming/Finanțe

Plăți/retrageri: Mokes trebuie să sprijine „Idempotency-Key”, „Retry-After”, HMAC/mTLS, coduri de sancțiuni și răspunsuri „lungi”.
Logica bonusului/antifraudă: scenarii de viteză/429, ATO/provocare, soluții de risc „allow/deny/challenge” cu TTL.
KYC/AML: răspunsuri la sandbox după nivelurile KYC, negative (neconcordanță, documente nevalide), cărți web cu anti-reluare (fereastra „X-Timestamp”).
Jurisdicții/Chiriași: rubricile necesare „X-Tenant/X-Region”, diferite profiluri de răspuns.

13) Mini rețete (foaie de ieftin)

Repetați plata: WireMock „Scenarii” - primul „201”, al doilea „409 duplicat”.
PSP lent: MockServer 'responseDelay' + verificarea timpului de încercare pe client.
Carti web: server HTTP local + verificare semnatura HMAC; reluarea după 5 secunde nu creează o dublă.
Duplicate Kafka: postați același mesaj de două ori; handler trebuie să fie idempotent.
Statusuri gRPC: matrice de teste „coduri” (InvalidArgument, DeadlineExceeded, ResourceEquausted).

14) Lista de verificare Prod Readiness

• Porturile/adaptoarele sunt evidențiate; integrările sunt ascunse în spatele interfețelor.
• Pentru HTTP/gRPC - există stabs conștiente de contract (Pact/OpenAPI/Proto) cu negative.
• Pentru brokeri - Testcontainere + Registry; teste duplicat/ordine/mesaj mare.
• Haos: întârzieri, termene, resetare, 429/503 cu „Retry-After”; rețeaua este emulată (Toxiproxi/netem).
• Corpuri fără PII; ceas fals; Idempotența este bătută.
• Matrice CI: unitate componentă integrare ; artefacte jurnal/contract sunt conservate.
• Furnizor de cutii de nisip: cheile sunt separate, punctele finale sunt configurate, există un runbook.
• Înregistrare/Replay este actualizat la program, urmele sunt editate.
• metrici fulgi și durate de testare sub control; alerte la creştere.

15) TL; DR

Izolați integrările prin porturi subțiri și utilizați instrumentul potrivit pentru sarcină: butuci pentru cazuri simple, batjocuri pentru verificarea interacțiunilor, falsuri pentru comportament realist, virtualizare a serviciilor și haos pentru rețea și erori rare. Asigurați-moki conștient de contract (Pact/OpenAPI/Proto), păstrați remedierile deterministe și fără PII, simulați întârzieri/timeout/429/5xx. În CI, construiți o piramidă: unitate → componentă → integrare; bloc de eliberare cu contracte roșii. Pentru căile de plată/CCM, luați în considerare HMAC/mTLS, idempotența și scenariile negative.