Testy

Testy Speedwave rozkładają się na kilka warstw: crate’y Rusta, serwery MCP, CLI, desktopowy interfejs w Angularze oraz scenariusze end-to-end sprawdzające zarówno CLI, jak i spakowaną aplikację Desktop. Uruchom tę warstwę, której dotyczą twoje zmiany, a o resztę przed scaleniem zadba CI. Jeśli nie masz jeszcze przygotowanego środowiska narzędzi, zacznij od konfiguracji środowiska deweloperskiego.

Uruchamianie testów

make test uruchamia wszystko: Rusta, Angulara, MCP, entrypoint, konfigurację oraz sprawdzenia budowania Desktopa. Aby lokalne iteracje szły szybciej, uruchamiaj tylko tę warstwę, której dotknęły twoje zmiany:

Polecenie	Co uruchamia
make test-rust	Testy jednostkowe i integracyjne Rusta (speedwave-runtime, speedwave-cli)
make test-cli	Testy specyficzne dla CLI
make test-mcp	Wszystkie testy przestrzeni roboczych MCP (shared, hub, Slack, GitLab i tak dalej)
make test-angular	Testy desktopowego interfejsu w Angularze
make test-e2e	Testy end-to-end CLI na debugowej wersji CLI (wymaga bats-core)
make test-entrypoint	Testy skryptu entrypoint kontenera (wymaga bats-core)
make test-desktop	Testy integracyjne Desktopa, budujące najpierw CLI, Angulara, MCP i systemowe CLI

Testy E2E Desktopa nie należą do domyślnego celu make test, ponieważ trwają znacznie dłużej.

Pokrycie testami

make coverage liczy pokrycie Rusta, MCP i Angulara naraz, a poszczególne warstwy uruchomisz osobno przez make coverage-rust, make coverage-mcp, make coverage-angular. Progi dla MCP i Angulara siedzą w pliku vitest.config.ts w każdej z przestrzeni roboczych, a pokrycie Rusta nie może zejść poniżej 70% linii. Przestrzenie robocze MCP trzymają zwykle 100% linii i funkcji, poza kilkoma wyjątkami, które są o parę punktów niżej.

Pokrycie workera Office MCP ma dwutorową historię, którą warto znać: stuprocentowy wynik z vitest obejmuje warstwę orkiestracji w TypeScripcie (politykę ścieżek, budowanie argv, obsługę błędów), natomiast owijane przez nią podprocesy, takie jak pandoc, soffice i pythonowe skrypty budujące, są w tym zestawie testów zamockowane. Te skrypty naprawdę wykonuje make test-mcp-office-py, który stawia jednorazowe środowisko wirtualne i ponownie otwiera wygenerowane dokumenty prawdziwymi bibliotekami. Uruchamia się to w zadaniu test w CI, a nie pod make coverage-mcp.

Testy end-to-end Desktopa

Testy E2E Desktopa sterują wydaniową binarką Tauri za pomocą WebdriverIO. Aplikacja ma wbudowaną wtyczkę tauri-plugin-webdriver, która udostępnia W3C WebDriver na porcie 4445, więc na żadnej platformie nie potrzebujesz zewnętrznej binarki sterownika.

make test-e2e-desktop buduje wydaniową binarkę na twojej bieżącej maszynie i uruchamia na niej zestaw WebdriverIO. Na macOS potrzebne są narzędzia wiersza poleceń Xcode, Rust i Node.js; na Windowsie Rust, Node.js i WebView2.

Aby pokryć obie wspierane platformy, make test-e2e-all uruchamia zestaw na macOS i Windowsie równolegle, przez SSH na wyznaczonych maszynach testowych (SPEEDWAVE_WINDOWS_HOST, SPEEDWAVE_MACOS_HOST). Każda platforma przechodzi trzy fazy: buduje wydaniowy artefakt, instaluje go od zera i uruchamia zestaw, a potem czyści cały stan i powtarza instalację oraz uruchomienie po raz drugi. Ta druga świeża instalacja wychwytuje stan, który przetrwałby zwykłe czyszczenie danych użytkownika, na przykład pozostały cache Limy albo dystrybucję WSL2.

18 plików ze specyfikacjami (desktop/e2e/specs/) uruchamia się w większości w kolejności numerycznej i pokrywa cykl życia aplikacji, kreator konfiguracji, kondycję kontenera, nawigację, ustawienia oraz zarządzanie projektami, a następnie czat, dostawców, integracje, logi i logowanie OAuth. Jedynym wyjątkiem jest 07-factory-reset.spec.ts: konfiguracja wdio przesuwa go na sam koniec przebiegu bez względu na numer, bo czyści on lokalny stan i restartuje aplikację, więc nic, co uruchomiłoby się po nim, i tak by tego nie przetrwało. Wszystkie elementy interaktywne mają atrybuty data-testid, po których te testy je odnajdują.

Wzorce testów Rusta i MCP

Testy jednostkowe Rusta mieszczą się w #[cfg(test)] mod tests na końcu swojego pliku źródłowego, a testy integracyjne w katalogu tests/ każdego crate’a. Testy narzędzi MCP importują fabrykę createXTools() danego narzędzia (zwraca ona obiekty ToolDefinition[] z polami tool i handler), mockują klienta usługi i pokrywają kształt metadanych, przypadki powodzenia, walidację parametrów oraz obsługę błędów. Desktopowe testy Angulara podstawiają MockTauriService w miejsce poleceń Tauri.