Dlaczego za każdym razem testujemy w ośmiu środowiskach linuksowych

W Linuksie stwierdzenie, że coś „działa”, nie wystarcza.

Nawet w Ubuntu biblioteki systemowe i zestawy narzędzi różnią się zależnie od wersji. Sposób wyświetlania obrazu dzieli się na X11 i Wayland, a do wprowadzania tekstu koreańskiego używa się ibus lub fcitx5. Gdy dodamy do tego sposób instalacji, liczba kombinacji wymagających sprawdzenia szybko rośnie.

To, że aplikacja uruchomiła się na jednym komputerze deweloperskim, oznacza jedynie, że sprawdzono jedną z wielu kombinacji.

Dlatego w repozytorium stworzyliśmy małe laboratorium. Dla każdego środowiska uruchamiamy prawdziwą maszynę wirtualną i powtarzamy te same testy. Wyniki zbieramy w jednej tabeli.

Tabela sprawdza proste rzeczy.

Czy aplikacja się uruchamia. Czy można wprowadzać tekst koreański.

Sami przechodzimy przez pierwsze trzydzieści sekund, których doświadczy użytkownik po zainstalowaniu aplikacji.

Każde środowisko zapisaliśmy w jednym pliku

Laboratorium korzysta z maszyn wirtualnych KVM zamiast kontenerów. Wynika to z tego, że w kontenerach trudno prawidłowo odtworzyć rzeczywistą sesję pulpitu i demona metody wprowadzania.

Pobieramy obraz chmurowy dystrybucji i przygotowujemy go za pomocą cloud-init. Dysk tworzymy jako warstwę nakładkową na oryginalnym obrazie. Jeśli pojawi się problem, możemy go odrzucić i zacząć od nowa.

Każde środowisko deklarujemy w jednym pliku. Plik zawiera dystrybucję, obraz, sesję, metodę wprowadzania oraz pakiet przeznaczony do instalacji. Aby sprawdzić nową kombinację, wystarczy dodać jeden plik.

Sposób wprowadzania zależy od sesji. W X11 używamy xdotool, a w Waylandzie — ydotool. Wayland nie udostępnia listy okien, dlatego uruchamiamy aplikację na pełnym ekranie w kompozytorze kioskowym. Dzięki temu za każdym razem możemy wprowadzać tekst w tym samym miejscu.

Aplikację budujemy tylko raz na hoście. Ten sam plik binarny kopiujemy bez zmian do wszystkich maszyn wirtualnych.

Gdybyśmy budowali ją ponownie w każdym środowisku, na wyniki wpływałyby różne kompilatory i biblioteki. W razie niepowodzenia trudniej byłoby znaleźć przyczynę. Przede wszystkim plik otrzymywany przez użytkownika musi być tym samym plikiem, który sprawdza laboratorium.

Maszyna wirtualna testuje, a host zapisuje wyniki

W maszynie wirtualnej sprawdzamy trzy rzeczy.

Sprawdzamy, czy plik binarny się uruchamia, czy pojawia się okno oraz czy po wpisaniu dkssud pojawia się 안녕.

Każdy test pozostawia jeden wiersz JSON. Host zbiera wyniki, zapisuje je w pliku i tworzy tabelę. Zmierzone wyniki pozostają w repozytorium, aby można je było porównać z kolejnym testem.

Sposób sprawdzania wprowadzania tekstu koreańskiego zależy od kompilacji. W kompilacji deweloperskiej możemy od razu sprawdzić znaki znajdujące się w trakcie składania. Rzeczywista kompilacja dystrybucyjna nie ma tej funkcji. Zamiast tego naciskamy Enter, zapisujemy plik, a następnie odczytujemy zawartość zapisaną na dysku.

Podczas tego procesu nauczyliśmy się jednej rzeczy. O metodzie testowania decydował nie sposób instalacji, lecz typ kompilacji aplikacji.

Pierwsza tabela ujawniła dwie rzeczy

W Ubuntu 22.04 aplikacja zbudowana przy użyciu systemowego zestawu narzędzi nie uruchamiała się. Wynikało to z tego, że nie mogła znaleźć symbolu dostępnego wyłącznie w najnowszej wersji libadwaita.

Po raz pierwszy potwierdziliśmy również, że w kombinacji Waylanda i ibus tekst koreański jest wprowadzany prawidłowo.

Na podstawie tych wyników postanowiliśmy dołączać ten sam zestaw narzędzi do wszystkich sposobów instalacji. Obecna tabela z ośmioma wierszami jest zabezpieczeniem pozwalającym sprawdzić, czy ta decyzja nie została ponownie naruszona.

Pojawiły się również problemy widoczne tylko w rzeczywistym środowisku. W przeciwieństwie do desktopowego Ubuntu obrazy chmurowe nie zawierały modułu wprowadzania GTK4 ani początkowego trybu wprowadzania. Trzeba je było osobno zainstalować podczas przygotowywania środowiska.

Moduł ibus musiał być zgodny z wersją demona zainstalowaną w dystrybucji. Sposób korzystania z narzędzi do wprowadzania również różnił się między dystrybucjami. Musieliśmy podzielić skrypty testowe tak, aby pasowały do poszczególnych środowisk.

Aby oszczędzać pamięć hosta, uruchamiamy jednocześnie najwyżej dwie maszyny wirtualne. Maszyna wirtualna jest wyłączana natychmiast po otrzymaniu wyników.

Wszystkie te problemy trudno byłoby znaleźć, czytając wyłącznie kod. Ten sam kod dawał bowiem różne wyniki zależnie od środowiska. Dlatego potrzebowaliśmy tabeli.

Tabela nie stanowi obietnicy wydajności

Tabela zapisuje również czas potrzebny do wyświetlenia pierwszego ekranu oraz zużycie pamięci. Nie używamy ich jednak jako wskaźników wydajności.

Maszyny wirtualne renderują obraz programowo bez GPU, a pomiar przeprowadzamy tylko raz, tuż po uruchomieniu systemu. Wartości mogą się zmieniać przy każdym uruchomieniu. Kryterium wydajności wyznaczamy jako medianę trzech pomiarów wykonanych na hoście wyposażonym w prawdziwy procesor graficzny.

W tej tabeli należy patrzeć nie na milisekundy, lecz na znaczniki wyboru.

Środowiska, których nie udało się sprawdzić, pozostawiamy puste. Fedora i Debian, rzeczywista sesja GNOME oraz portalowe okna dialogowe, takie jak wybór pliku, nie znajdują się jeszcze w tabeli.

Nie wypełniamy niesprawdzonych pól stwierdzeniem, że „prawdopodobnie zadziała”.

Nie możemy decydować, jakie środowisko wybierze użytkownik. Możemy natomiast wejść do niego przed użytkownikiem i spróbować uruchomić aplikację.