Testowanie i weryfikacja

Projekt Speedwave opiera się na wielowarstwowej piramidzie testów automatycznych: testach jednostkowych i integracyjnych w Rust, testach pakietów MCP w TypeScript, testach komponentów Angulara oraz testach end-to-end (E2E) w WebdriverIO. Przed zgłoszeniem pull requesta upewnij się, że modyfikacje przechodzą odpowiednie pakiety testowe. Wytyczne konfiguracyjne znajdziesz w rozdziale Konfiguracja środowiska deweloperskiego.

Uruchamianie zestawów testowych

Polecenie make test uruchamia wszystkie podstawowe pakiety testów w monorepozytorium. Do szybkiej pracy lokalnej (TDD) służą wyznaczone cele cząstkowe:

Cel w pliku Makefile	Zakres testów
`make test-rust`	Testy jednostkowe i integracyjne w Rust (`speedwave-runtime`, `speedwave-cli`).
`make test-cli`	Testy parsowania argumentów i podpoleceń interfejsu CLI.
`make test-mcp`	Wszystkie serwery MCP (shared, hub, Slack, GitHub itp.).
`make test-angular`	Testy jednostkowe i komponentowe frontendu w Angularze.
`make test-e2e`	Testy integracyjne CLI oparte na środowisku Bats.
`make test-entrypoint`	Testy skryptów startowych kontenerów (Bats).
`make test-desktop`	Testy integracyjne aplikacji Desktop.

Wskaźniki pokrycia kodu

Polecenie make coverage generuje zbiorcze raporty pokrycia testami. Bramki jakości CI wymuszają określone progi:

Crate’y w Rust: Wymagane minimum 70% pokrycia linii kodu.
Pakiety MCP: Docelowe 100% pokrycia funkcji i linii zdefiniowane w vitest.config.ts.
Walidacja parserów Office: Cel make test-mcp-office-py uruchamia rzeczywiste testy parsowania plików Word, Excel i PowerPoint w odizolowanym środowisku Python.

Testy end-to-end aplikacji Desktop (WebdriverIO)

Testy E2E sterują skompilowaną aplikacją Tauri za pośrednictwem wbudowanej wtyczki tauri-plugin-webdriver (nasłuchującej na porcie 4445):

make test-e2e-desktop

Porządek wykonywania: 18 zestawów testowych (desktop/e2e/specs/) weryfikuje kreator instalacji, kondycję kontenerów, konfigurację projektów, strumieniowanie odpowiedzi LLM oraz logowanie OAuth.
Izolacja operacji resetu: Destrukcyjny scenariusz 07-factory-reset.spec.ts jest zawsze wykonywany jako ostatni krok testów.
Stabilność selektorów: Wszystkie interaktywne kontrolki w interfejsie posiadają unikalne atrybuty data-testid.

Wzorce architektoniczne i mockowanie

Testy w języku Rust: Testy jednostkowe znajdują się w modułach #[cfg(test)] mod tests w plikach źródłowych; testy integracyjne są umieszczone w katalogu tests/.
Serwery MCP: Narzędzia są testowane przez funkcje fabryczne (createXTools()) z zamockowanymi klientami API w celu weryfikacji schematów argumentów i logiki błędów.
Frontend w Angularze: Komunikacja z backendem Tauri jest mockowana za pośrednictwem serwisu MockTauriService.