Strategia de testare a kernelului

1) Principii

Echilibru piramidă-trofeu. Baza - încercări modulare și contractuale rapide; mai sus - componentă și integrare; la vârf este stratul e2e minim, dar valoros.
Shift-stânga. Cu cât prindem mai devreme defectul (linter, analiză statică, bazată pe proprietate), cu atât mai ieftin.
Determinist prin design. Gestionăm dependențele de timp, rețea, aleatorii și externe.
Economie de calitate. Orice test este „asigurare”: scopul este de a minimiza costurile totale (defecte + întreținere test).
Orientarea către risc. Acoperirea se concentrează asupra invarianților și protocoalelor de afaceri (contracte, idempotență, consecvență).

2) Niveluri de testare și domenii de responsabilitate

2. 1 Unitate (modulară)

Verificați logica pură fără I/O.
Umezim doar limitele (port/adaptor), folosim fabrici pentru date.
Rapid (≤50 -100 ms/test), paralel.

2. 2 Contract (furnizor ↔ consumator)

Fixați contractele API (HTTP/gRPC/eveniment) între servicii.
Utilizăm o abordare bazată pe consumatori: contractele sunt stocate în VCS, verificate în CI-ul furnizorului.
Reducerea fragilității integrării e2e.

2. 3 Componenta (deasupra modulului, cu stocare reala)

Lansăm o parte a serviciului cu o bază de date reală/memorie cache într-un container (Testcontainere).
Validăm migrațiile schemelor, indicii, tranzacțiile, încuietorile.

2. 4 Integrare/Sistem (căi end-to-end între servicii)

Ridicăm un set de servicii într-un mediu izolat.
Verificăm invarianții end-to-end: tranzacționalitate, retrai, idempotență, manipularea erorilor.

2. 5 E2E (strat minim „valoros”)

Protocoale reale și mediu „ca în vânzări”, dar un scenariu limitat stabilit: plată → confirmare → postare; înregistrare → verificare → intrare.
Folosim caracteristici cu risc ridicat pentru eliberare și regresie.

3) Arhitectură testabilă

Porturi/adaptoare (hexagonale). Kernelul de afaceri nu știe despre HTTP/SQL; dependențele sunt implementate prin interfețe.
Injectarea timpului/aleatoriu. "Ceas'," Aleatoriu "- dependențe; în testele pe care le reparăm.
Abstractizare I/O configurabilă. Cozi, DB, KMS - prin interfețe cu implementări de testare.
Invarianţi funcţionali. Formulăm în mod explicit postcondiții și predicate - sunt mai ușor de testat și monitorizat.

4) Date pentru teste

Fabrici/constructori în loc de corpuri statice JSON: mai puțină fragilitate.
Semințe idempotente și resetați cârligul DB înainte de încercare (migrații → trunchiază semințele de →).
Cataloage de cazuri: „norme”, „margini”, „erori”, „haos”.
Sintetice în loc de PD real: generatoare, mascare, profile de confidențialitate.

5) Concurența și idempotența

Teste de curse: Intrări/rezerve/încuietori competitive.
Verificarea tastelor idempotente (de exemplu, „(operație, external_id)”): apelurile repetate nu schimbă starea.
Retrai și timeout: garantăm corectitudinea în caz de erori temporare.

dedupe_key = hash(op + external_id)
if exists(executions, dedupe_key): return previous_result else:
reserve(dedupe_key)
result = do_operation()
store(executions, dedupe_key, result)
return result

6) Timp, timeout, fusuri orare

Toate orele stocate sunt UTC; în teste folosim „FixedClock”.
Testăm cazuri DST (duplicate/ceasuri), ferestre „locale”.
Verificăm timeouturile cu un ceas monotonic; simula NTP jitter.

7) Reziliență și haos

Injecție de erori: erori de rețea, 5xx, întârzieri, degradare parțială (cache indisponibil).
Teste de haos în mediul pre-prod: deconectarea nodurilor, supraîncărcarea cozilor, ruperea BGP/Anycast (emulare).
Politicile de rezervă și degradarea UX: testele trebuie să confirme „degradarea grațioasă” corectă.

8) Performanță

Micro repere pentru algoritmi critici (cu fixare CPU/allocare).
Profile de încărcare: linie de bază (p50/p95), stres (vârf), extins (înmuiere) pentru scurgeri de memorie.
Regress gates: build fails if p95 latency is greater than baseline> X%.

9) Siguranță și conformitate

SAST/Lint: căutați vulnerabilități/antipatterns.
DAST/IAST: scenarii de bază la stand (probe XSS/SQLi/SSRF).
Secrets-scan: fără chei/parole în cod și artefacte.
Teste de confidențialitate: lipsa PD în jurnale/urme, respectarea „managementului consimțământului”, profiluri de anonimizare pentru încărcări.

10) Măsurători de calitate și SLO

Rata de trecere a testului și indicele fulguos.

• 90-100% pentru module critice de nucleu,
• 70-80% pentru periferie (cu accent pe invarianți).
• Scor de risc de eliberare: totalitate: modificări în fișierele critice × care se încadrează repere × nou flaky.
• Buget eronat: o combinație de prod-SLO (uptime/erori) cu experimente și frecvența de eliberare.

11) CI/CD și porți

1. Lint/Format/TypeCheck

2. Unitate + Bazat pe proprietate

3. Prestator/consumator contract

4. Componentă (Testcontainere)

5. Integrare + Fum Perf

6. Securitate (SAST/Secrete)

7. Construi/Pachet + SBOM

8. Implementați la pre-prod + e2e + fum haos

Gates: opriți la contractele care se încadrează, creșterea latenței, noi vulnerabilități critice.

Cache și sharding: accelerarea conductei din cauza paralelismului și a rulajelor incrementale (pentru module modificate).

12) Teste cu fulgi: detectare și tratament

Autorun + Quorum (2/3 de runde).
Detector de model Flaki: dependență de timp/așteptări aleatorii/implicite.
Carantina cu SLA: testul nu blochează eliberările, ci trebuie corectat/rescris în zilele N.
Toleranță zero la flucuri în „miezul” căii critice.

13) Testarea pe bază de proprietăți, a mutațiilor și a fazelor

Bazat pe proprietăți: formulăm proprietăți (comutativitate, idempotență, monotonie), generatoare de date limită.
Testarea mutației: măsurăm „puterea” testelor (dacă acestea ucid mutațiile introduse).
Fuzzing: protocoale/parsere/formate (JSON, Protobuf, CSV), în special la limitele de securitate.

prop "serialize/deserialize roundtrip":
forAll(randomModel()):
decode(encode(model)) == model

14) Observabilitatea și asocierea cu testele

Urme de testare (trace-id în bușteni): este convenabil să se reproducă în pre-prod.
Instantaneele de măsurare în timpul unei alergări de performanță sunt stocate ca un artefact.
Control jurnal: fără câmpuri sensibile, dimensiune jurnal în cadrul SLO.

15) Documentație și proceduri

Manual de testare: unde să rulați ce teste, cum să scrieți fabrici, cum să actualizați contractele.
Runbooks: reluare incident, diagnostic rapid, eliberare rollback.
Catalog invariant: lista garanțiilor sistemului și trimiteri la testele/alertele relevante.

16) Lista de verificare a arhitectului

1. Invarianți de nucleu și căi critice descrise?
2. Există o matrice de niveluri de testare și SLO (timp, stabilitate)?
3. Contractele sunt versionate și validate în CI la furnizor și consumator?
4. Timp/aleatoriu/rețea controlată în teste (FixedClock, Fault-injector)?
5. Testcontainere configurate/baze de date izolate, sunt verificate migrațiile?
6. Există linii de bază de performanță și porți de regresie?
7. Sunt activate verificările SAST/Secrets-scan și privacy log?
8. Flaky este înregistrat și există un SLA pentru corectare?
9. Este transparentă legătura dintre teste și prod-SLO și bugetul eronat?
10. Runbook-ul și catalogul invariant sunt documentate?

Concluzie

Strategia de testare a nucleului nu este o listă de instrumente, ci o capacitate arhitecturală: design testabil, ierarhie strictă a nivelului, date gestionate, toleranță la erori și metrici încorporate în CI/CD. Urmând practicile descrise, echipa primește feedback rapid și de încredere, iar versiunile devin previzibile și sigure.