chimera-test-the-wiring-not-the-class

Zbudowałeś komponent, do którego produkcja dociera pośrednio: przez fabrykę, rejestr, loader wtyczek, flagę konfiguracji, router, punkt wejścia CLI, kontener wstrzykiwania zależności. Twoje testy konstruują go bezpośrednio i wołają jego metody.

Każdy z tych testów może przechodzić, podczas gdy komponent jest w działającym systemie nieosiągalny — bo żaden z nich nie ćwiczy rejestracji, wartości domyślnej flagi ani gałęzi w składaczu, która decyduje, czy w ogóle go dołączyć.

Nie dotyczy to czystej funkcji, którą wywołujący importują i wołają wprost. Tam import jest okablowaniem, a test jednostkowy je pokrywa. Nie dotyczy też sytuacji, gdy świadomie testujesz algorytm w izolacji — te testy są poprawne i powinny zostać; ta karta mówi, że same w sobie nie wystarczają.

1. Nazwij punkt wejścia, w który użytkownik faktycznie uderza: podpolecenie CLI, trasę HTTP, pętlę uruchomieniową agenta, zaplanowany job. Zapisz go, zanim napiszesz test.

2. Napisz co najmniej jeden test, który zaczyna się tam i nie przekazuje żadnych argumentów konstruktora dla twojego komponentu. Jeśli test musi nazwać twoją klasę, żeby funkcja się wydarzyła, to nie testuje okablowania.

3. Zbuduj obiekt tak, jak buduje go produkcja — wołając prawdziwą fabrykę albo loader konfiguracji:

   # WRONG — proves the class, not the wiring: the component is handed to the thing under test,
   # so the test passes whether or not anything in production ever hands it over.
   assert "reminder" in render(feature=Feature(text="reminder"))
   
   # RIGHT — build it the way the entry point builds it, then look for the same observable
   assert "reminder" in build_the_real_way(config).render()
   

   Własny przypadek Chimery warto nazwać, bo klasa nigdy nie była zepsuta. Skill cards miały działający retriever, działający store i działający injector — a chimera/config.py:244 mówi skill_cards: bool = Field(default=False, ...), więc na standardowym wdrożeniu nic nigdy nie zostało wstrzyknięte. Każdy test jednostkowy przechodził. Pomiar, który to w końcu wyłapał, policzył skille wybite wobec skilli wstrzykniętych i znalazł 39 wobec zera.

4. Sprawdzaj obserwowalną rzecz, która może pojawić się tylko wtedy, gdy komponent został osiągnięty: tekst w wyrenderowanym promptcie, zapisany wiersz, linię logu, kod wyjścia.

5. Sprawdzaj wartość domyślną. Jeśli funkcja jedzie za flagą, dodaj osobny test, który odczytuje wartość domyślną bez żadnych nadpisań i sprawdza, jaka ona jest. Zestaw, który zawsze biegnie z flagą wymuszoną na włączoną, nie powie ci, co dostają użytkownicy.

Testy z punktu wejścia są wolniejsze, trudniejsze do debugowania i gorzej lokalizują: gdy jeden zawiedzie, wiesz, że funkcja jest zepsuta, ale nie który z dziesięciu komponentów ją zepsuł. To prawdziwy koszt, a złą odpowiedzią na tę kartę jest usunięcie testów jednostkowych na rzecz end-to-end. Zachowaj oba — test okablowania mówi ci, że się zepsuło, test jednostkowy mówi, co.

Przechodzenie przez prawdziwy punkt wejścia może też dotknąć rzeczy, których nie chcesz dotykać w CI: płatnego API, żywej bazy danych, systemu plików poza sandboxem. Jeśli jedynym sposobem dotarcia do punktu wejścia jest wydanie pieniędzy albo zmutowanie produkcji, nie wymuszaj tego; pokryj zamiast tego funkcję składającą bezpośrednio i przyjmij, że jesteś o krok od prawdziwej ścieżki.

A ta karta wyłapuje osiągalność, nie poprawność. Funkcja może być idealnie okablowana do punktu wejścia i wciąż produkować złą odpowiedź, więc zielony test okablowania nie jest licencją na pominięcie sprawdzenia, co wyjście faktycznie mówi.