Unități vs Teste de integrare

1) De ce distinge între tipurile de testare

Granularea corectă a testelor face dezvoltarea previzibilă: defectele logice de captură a unităților rapid și ieftin; Integrarea verifică pachete de module, transport real și "lipici. "Împreună, acestea reduc regresia și accelerează eliberările.

2) Definiții și limite

Încercare de unitate

Testează o unitate mică de comportament (funcție, clasă, utilizare-caz) în izolare.
Dependențele externe sunt înlocuite (mock/stub/fake).
Rapid (ms-zeci de ms), determinist.

Test de integrare

Verifică interacțiunea mai multor componente reale: bază de date, broker (Kafka/RabbitMQ), HTTP/gRPC, sistem de fișiere, cache.
Mocs minime, protocoale reale.
Mai lent (sute de ms-secunde), mai scump în sprijin.

3) Testarea piramidei (nu cornul de gheață)

Fundație: Unitate (70-80% la număr) - ieftin, rapid.
Strat de mijloc: Integrare/Componentă (15-25%) - căi critice și contracte.
Top: E2E/UX/Exploratory (5-10%) - minim suficient.
Pe părțile laterale: Static Analysis/Lint/Type check and Mutation testing as quality amplificators.

4) Ce să dați unității și ce să integrați

5) Date și remedieri

Unitate

Ficțiuni/constructori inline (metode din fabrică).
Teste bazate pe tabel pentru valori limită.
Abordare bazată pe proprietăți pentru invarianți (de ex. „suma debitelor = suma creditelor”).

Integrare

Mediu ermetic: Testcontainere/Docker Compune ridica 'postgres + redis + kafka + wiremock'.
Semințe inițiale în baza de date/cache și curățare după (tranzacție/rollback, trunchiat).
Ceasuri/cronometre sunt false (controlate), în caz contrar flacks.

6) Instrumente și modele

• Stub este un răspuns fix (ieftin).
• Mock - verificați interacțiunile/numărul de apeluri.
• Fake este o implementare simplificată (de exemplu, In-Memory Repo).
• Testarea contractelor (CDC): Pact/Swagger - fixați așteptările clienților și verificați furnizorul.
• WireMock/MockServer - HTTP pentru servicii terțe părți.
• Testcontainerele sunt live DBs/brokeri la nivel local și în CI fără o „grădină zoologică”.

7) Exemple

7. 1 Unitate: Idempotence de plată (pseudocod)

python def test_idempotent_create_payment_returns_same_id():
repo = InMemoryPayments()
service = Payments(repo)

first = service. create(amount=100, key="abc")
second = service. create(amount=100, key="abc")

assert first. id == second. id assert repo. count() == 1

7. 2 Integrare: Semnătură broşură web (HMAC) + Repetare

bash docker-compose: app + redis + wiremock (PSP)
docker compose -f docker-compose. test. yml up -d pytest -m "integration and webhook" -q

• WireMock oferă un eveniment cu un 'X-Timestamp' și o semnătură.
• Aplicația verifică HMAC, deduplicates by 'event _ id', repetă după 5 secunde nu creează o dublă.
• Verificăm „200” și că există o singură intrare.

7. 3 CDC: Contractul clientului cu furnizorul

Clientul generează un Pact (în așteptare: „POST/v1/payout” → „201” cu o diagramă).
Furnizorul din CI efectuează verificarea contractului la standul său.

8) Viteză, paralelism, fulgi

Unitățile trebuie să ruleze <100 ms per test; pachet - secunde.
Integrare - paralel cu containere/porturi; utilizați migrațiile de pornire.

• timp controlat (ceas fals),
• așteptări "prin eveniment explicit", nu "somn',
• praguri stabile (retrai cu testul jitter deterministic).

9) Măsurători ale calității

Acoperire (linii/ramuri): utilă pentru observarea tendinței, dar nu și a țintei.
Testarea mutațiilor (PIT/Mutmut): Arată dacă testele „ucid” schimbări false - puterea reală a asasinilor.
Durata testului și rata de fulguială: alerte la creștere.
Izolarea defectelor: proporția de bug-uri interceptate înainte de producție.

10) Încorporarea în CI/CD

Locuri de muncă: unitate → integrare → e2e (fan-out prin serviciu).
Cache de dependență, matrice paralele prin bază de date/limbă/versiune.
Rapoarte: JUnit/Allure + artefacte jurnal container (pentru picături).
Poarta: „unitate verde + integrare critică” - stare de îmbinare; e2e - pe timp de noapte.

yaml strategy:
matrix:
db: [postgres14, postgres16]
steps:
- run: docker run -d --name db -e POSTGRES_PASSWORD=pw postgres:${{ matrix. db }}
- run: pytest -m "unit" -q
- run: pytest -m "integration" -q

11) Microservicii și evenimente

Contracte de servicii: OpenAPI/Protobuf sunt versionate; teste de compatibilitate (înapoi).

• Unitate: maparea evenimentelor de domeniu și invarianți.
• Integrare: publicare/abonare într-un broker real (Kafka), semantică outbox/inbox, imitație exact o dată (cel puțin - idempotent).
• Teste în afara ordinii.

12) Date și izolare în integrare

Fiecare test → o schemă unică/bază de date (Testcontainers JDBC URL'? TC _ TMPFS =/var/rob/postgresql/data: rw ').
Remedierile tranzacționale (begin→run→rollback) accelerează curățarea.
Pentru Redis/cache, prefixul cheie este 'test: $ {RUN _ ID}:' și 'FLUSHDB' în rupere.

13) Specificul iGaming/Finanțe

Bani și limite: teste bazate pe proprietate pentru invarianți (sold ≥ 0, restricții totale).
Reglementare: verificare logare (jurnalul de audit este scris), evenimente neschimbabile.
Plăți/PSP: teste de integrare HMAC/mTLS, 'Retry-After', idempotency, dedup 'jti'.
Joc responsabil: pragul/testele regulilor de reactivare; „vchera→segodnya” pe ceas fals.

14) Antipattern

„Unitățile” care ridică DB/HTTP sunt deja integrate (confundă straturile și încetinesc CI).
Acoperire ridicată din cauza declarațiilor goale („acoperite, dar nu verificate”).
Logica Moki a serviciilor terță parte în cazul în care este necesar un contract (pauze atunci când este actualizat).
Teste cu „somn (5)” în loc de așteptări eveniment/condiție.
Baza de date de testare comună pentru teste paralele → rasă și fulg.

15) Lista de verificare Prod Readiness

• Piramida definit ca% din Unit/Integration/E2E și acțiuni țintă de timp.
• Unitățile sunt izolate, rapide, acoperă valorile limită și invarianții.
• Integrarea folosește un mediu ermetic (Testcontainers/Compose), fără stări comune.
• Testele contractuale (OpenAPI/Pact) sunt verificate în CI.
• Date de testare - gestionate: semințe/rollback/prefixe, ceas fals.
• Paralel run, rapoarte JUnit/Allure, artefacte jurnal container.
• Metrica: durata, rata de fulguială, scorul mutației; alerte de degradare.
• Scenarii de plată/webhook: HMAC/mTLS, retrai, idempotency, deadup.
• Documentația strategiei și șabloanele de testare a eșantionului.

16) TL; DR

Unitate - logică maximă, mediu minim; Integrare - moks minime, realism maxim. Țineți piramida: Unitățile rapide prind 80% din defecte, Integrarea confirmă pachetele și contractele. Utilizați containere ermetice, teste de contract, ceas fals și paralelism. Măsura nu numai acoperire, dar, de asemenea, scorul mutației și rata de fulguială. Mai ales verificați căile de plată/webhook: semnături, retribuții și idempotență.