Strategia testowania jądra
1) Zasady
Bilans piramidy-trofeum. Podstawa - szybkie testy modułowe i kontraktowe; powyżej - komponent i integracja; na wierzchołku jest minimalna, ale cenna warstwa e2e.
Zmiana w lewo. Im wcześniej złapiemy wadę (liniowiec, analiza statyczna, nieruchomość), tym taniej.
Deterministyczny z projektowania. Zarządzamy czasem, siecią, losowymi i zewnętrznymi zależnościami.
Ekonomia jakości. Każdy test to „ubezpieczenie”: celem jest zminimalizowanie kosztów całkowitych (wady + konserwacja testów).
Orientacja ryzyka. Zasięg koncentruje się na stałych firmach i protokołach (umowy, idempotencja, spójność).
2) Poziomy badań i obszary odpowiedzialności
2. 1 Jednostka (modułowa)
Sprawdź czystą logikę bez I/O.
Moczymy tylko granice (port/adapter), używamy fabryk do danych.
Szybki (≤ 50 -100 ms/test), równoległy.
2. 2 Umowa (dostawca i konsument)
Naprawić umowy API (HTTP/gRPC/event) między usługami.
Stosujemy podejście konsumenckie: umowy są przechowywane w VCS, sprawdzane w CI dostawcy.
Zmniejszenie kruchości integracji e2e.
2. 3 Komponent (powyżej modułu, z rzeczywistym przechowywaniem)
Uruchamiamy część usługi z prawdziwą bazą danych/pamięci podręcznej w kontenerze (Testcontainers).
Sprawdzamy schematy migracji, indeksy, transakcje, zamki.
2. 4 Integracja/system (ścieżki end-to-end między usługami)
Podnosimy zestaw usług w odizolowanym środowisku.
Sprawdzamy trwałości od końca do końca: transakcyjność, retrai, idempotencja, obsługa błędów.
2. 5 E2E (minimalna warstwa „wartościowa”)
Prawdziwe protokoły i środowisko „jak w sprzedaży”, ale ograniczony zestaw scenariuszy: płatność → potwierdzenie → delegowanie; rejestracja → weryfikacja → wpis.
Wykorzystujemy funkcje wysokiego ryzyka do uwolnienia i regresji.
3) Sprawdzalna architektura
Porty/adaptery (sześciokątne). Jądro biznesowe nie wie o HTTP/SQL; zależności są realizowane poprzez interfejsy.
Wstrzyknięcie czasu/losowo. „zegar”, „losowy” - zależności; w testach, które naprawiamy.
Konfigurowalna abstrakcja we/wy. Kolejki, DB, KMS - poprzez interfejsy z implementacjami testowymi.
Niezmienne funkcje. Formułujemy wprost postkonditcje i predykaty - są one łatwiejsze do przetestowania i monitorowania.
4) Dane do badań
Fabryki/budownicze zamiast statycznych opraw JSON: mniej kruchości.
Idempotentne nasiona i zresetować hak DB przed testem (migracje → obciąć → nasiona).
Katalogi przypadków: „normy”, „krawędzie”, „błędy”, „chaos”.
Syntetyka zamiast prawdziwej PD: generatory, maskowanie, profile prywatności.
5) Konkurencja i idempotencja
Testy wyścigowe: Konkurencyjne wpisy/rezerwy/zamki.
Sprawdzanie kluczy idempotentnych (na przykład '(operacja, external_id)'): powtarzane połączenia nie zmieniają stanu.
Retrai i timeouts: gwarantujemy poprawność w przypadku tymczasowych błędów.
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 result6) Czas, godziny, strefy czasowe
Wszystkie przechowywane czasy to UTC; W testach używamy 'Zegara ".
Testujemy przypadki DST (duplikaty/brakuje zegara), okna „lokalnego dnia”.
Sprawdzamy timeouts z monotonicznym zegarem; symulować NTP jitter.
7) Odporność i chaos
Wtrysk usterki: błędy sieciowe, 5xx, opóźnienia, częściowa degradacja (pamięć podręczna niedostępna).
Testy chaosu w środowisku preprd: odłączanie węzłów, kolejki przeciążania, łamanie BGP/Anycast (emulacja).
Polityka awaryjna i degradacja UX: testy muszą potwierdzić prawidłową „wdzięczną degradację”.
8) Wydajność
Mikro wartości odniesienia dla algorytmów krytycznych (z utrwaleniem procesora/stopu).
Profile obciążenia: linia wyjściowa (p50/p95), naprężenie (szczyt), rozszerzenie (moczenie) dla wycieków pamięci.
Bramki regresowe: budowa nie powiodła się, jeśli opóźnienie p95 jest gorsze niż wartość wyjściowa> X%.
9) Bezpieczeństwo i zgodność
SAST/Lint: wyszukiwanie luk/antypaterii.
DAST/IAST: podstawowe scenariusze na stoisku (próbki XSS/SQLi/SSRF).
Sekrety-skanowanie: brak kluczy/haseł w kodzie i artefakcie.
Testy prywatności: brak danych PD w logach/śladach, zgodność z „zarządzania zgodą”, profile anonimizacji przesyłania.
10) Wskaźniki jakości i SLO
Szybkość przejścia testu i wskaźnik błędów.
Zasięg docelowy:- 90-100% dla modułów jądra krytycznego,
- 70-80% dla obwodu (ze szczególnym uwzględnieniem stałych).
- Ocena ryzyka uwolnienia: całość: zmiany w plikach krytycznych × spadające wartości odniesienia × nowe płatki.
- Błędny budżet: połączenie prod-SLO (uptime/errors) z eksperymentami i częstotliwością uwalniania.
11) CI/CD i bramy
Macierz etapowa:1. Wskazówka/Format/Sprawdź
2. Jednostka + Nieruchomości
3. Dostawca/konsument
4. Komponent (Testcontainers)
5. Integracja + dym perfowy
6. Bezpieczeństwo (SAST/Secrets)
7. Budowa/pakiet + SBOM
8. Wdrożyć do pre-prod + e2e + dym chaosu
Bramy: zatrzymać się na spadku kontraktów, rosnące opóźnienia, nowe krytyczne słabości.
Cache i shading: przyspieszyć rurociąg z powodu równoległości i przebiegów przyrostowych (dla modułów zmodyfikowanych).
12) Testy płatkowe: wykrywanie i leczenie
Autorun + Quorum (2/3 biegów).
Wykrywacz płatków: zależność od czasu/losowych/domyślnych oczekiwań.
Kwarantanna z SLA: badanie nie blokuje uwolnień, ale musi być skorygowane/przepisane w dniach N.
Zerowa tolerancja na strumienie w „rdzeniu” szlaku krytycznego.
13) Badanie własności, mutacja i faza
Właściwości oparte: formułujemy właściwości (komutacyjność, idempotencja, monotonia), generatory danych granicznych.
Badanie mutacji: mierzymy „siłę” testów (czy zabijają wprowadzone mutacje).
Fuzzing: protokoły/parsery/formaty (JSON, Protobuf, CSV), zwłaszcza na granicach bezpieczeństwa.
prop "serialize/deserialize roundtrip":
forAll(randomModel()):
decode(encode(model)) == model14) Obserwowalność i powiązanie z badaniami
Ślady testowe (ślad-id w dziennikach): wygodne jest replikowanie w preprd.
Migawki metryki podczas wykonywania są przechowywane jako artefakt.
Kontrola dziennika: brak pól wrażliwych, rozmiar dziennika w SLO.
15) Dokumentacja i procedury
Podręcznik testów: gdzie uruchomić, które testy, jak pisać fabryki, jak aktualizować kontrakty.
Książki startowe: powtórka incydent, szybka diagnoza, zwolnienie rollback.
Niezmienny katalog: wykaz gwarancji systemowych i odniesień do odpowiednich testów/wpisów.
16) Lista kontrolna architekta
1. Jądro niezmienne i krytyczne ścieżki opisane?
2. Czy istnieje macierz poziomów testów i ich SLO (czas, stabilność)?
3. Umowy są weryfikowane i zatwierdzane w CI u dostawcy i konsumenta?
4. Czas/losowy/sieć kontrolowana w testach (zegar, wtryskiwacz usterki)?
5. Skonfigurowane Testcontainers/izolowana baza danych, czy migracje są sprawdzone?
6. Czy istnieją granice i bramy regresji?
7. Czy SAST/Secrets-skanowanie i sprawdzanie dziennika prywatności są włączone?
8. Flaky jest nagrywany i jest SLA do korekty?
9. Czy związek między testami a prod-SLO a błędnym budżetem jest przejrzysty?
10. Czy książka startowa i niezmienny katalog są udokumentowane?
Wniosek
Strategia testowania jądra nie jest listą narzędzi, ale umiejętnością architektoniczną: sprawdzalna konstrukcja, ścisła hierarchia poziomu, zarządzane dane, tolerancja błędów i metryki wbudowane w płytę CI/CD. Zgodnie z opisanymi praktykami zespół otrzymuje szybkie i niezawodne informacje zwrotne, a wydania stają się przewidywalne i bezpieczne.