Czy Twój test Angulara sprawdził oczekiwane zachowanie użytkownika? Sześć scenariuszy w Vitest

Testy komponentów Angulara można uruchamiać w jsdom lub w prawdziwej przeglądarce przez Vitest Browser Mode. Przy wyborze środowiska warto zapytać, co konkretnie test ma potwierdzić: walidację formularza, przeniesienie fokusu, rozmiar kontenera czy możliwość kliknięcia przycisku wskaźnikiem.

Sprawdziliśmy sześć takich scenariuszy. Przed napisaniem testów dla każdego z nich określiliśmy oczekiwane zachowanie oraz jedną izolowaną mutację, która celowo je psuła. Sami wybraliśmy mutacje, żeby przeanalizować różne mechanizmy. To mały przykład testowy, a nie losowa próbka błędów działającej aplikacji.

Część tych mechanizmów dotyczy interfejsów webowych ogólnie. Tutaj sprawdzaliśmy je na komponentach Angulara; w S4–S5 szczegółowo widać rolę TestBed, sygnałów i odroczonego pozycjonowania.

Poprawną i wadliwą wersję każdego komponentu Angulara uruchomiliśmy na trzy sposoby:

• A: jsdom + synthetic actions. Vitest działa w jsdom, a interakcje wykonuje @testing-library/user-event.
• B: Chromium + synthetic actions. To samo podejście z @testing-library/user-event, ale test działa w Chromium w trybie headless przez Browser Mode.
• C: Chromium + provider actions. W tym samym Chromium używamy akcji z vitest/browser przez provider Playwright.

Eksperyment miał ustalić, które z wcześniej określonych wymagań użytkownika te testy sprawdzają w całości i jakich obserwacji im brakuje. Nie porównujemy szybkości i nie tworzymy rankingu narzędzi.

Różnicę między akcjami syntetycznymi a akcjami providera opisuje już Marmicode Cookbook, także na przykładzie zasłoniętego przycisku. Dodaliśmy sprawdzenie sześciu wcześniej wybranych mutacji, osobny hit test bez akcji providera oraz opis błędu we własnym teście geometrii.

Ogólny obraz: w S1–S3 jsdom wystarczył do sprawdzenia formularza, programowego fokusu i określonej sekwencji Tab. S4–S5 wymagały rzeczywistego layoutu przeglądarki. W S6 syntetyczny click wywoływał handler zasłoniętego przycisku, choć wskaźnik nie mógł w niego trafić. Taki test pozostawał zielony także po uruchomieniu w Chromium.

Co uznawaliśmy za pełne sprawdzenie

Zanim testowi można było przypisać wykrycie mutacji, musiał przejść na poprawnej wersji. Następnie sprawdzaliśmy, jaką część oczekiwanego zachowania rzeczywiście weryfikuje.

• bug_detected: poprawna wersja przeszła test, a wadliwa naruszyła całe wcześniej określone kryterium.
• partial: test sprawdził część tego kryterium.
• unsupported: w tym przykładzie testowym nie można wiarygodnie sprawdzić całego kryterium bez zastąpienia badanego zachowania.

unsupported odnosi się do pełnego zachowania w tym przykładzie. Mock pozwala sprawdzić reakcję na rozmiar lub argument observe(), ale są to inne asercje. partial i unsupported nie oznaczają false_negative, czyli pominięcia błędu przy pełnym sprawdzeniu.

Tabela dotyczy pierwotnych adapterów testowych, czyli kodu akcji, oczekiwań i asercji w każdym trybie. Późniejsza kontrola S6 przez elementFromPoint nie jest w niej uwzględniona; opisujemy ją osobno poniżej.

Komponenty, style i mutacje pozostawały takie same we wszystkich trybach. Adaptery się różniły: w S1 A/B używały type, a C używał fill; w S3 A/B wywoływały user-event.tab, a C wysyłał przeglądarkowy Tab. Dlatego tych wyników nie można przypisać jednej, całkowicie izolowanej właściwości środowiska.

Gdzie te scenariusze mieszczą się w piramidzie testów

We wszystkich sześciu scenariuszach montowaliśmy pojedynczy komponent przez TestBed i sprawdzaliśmy go razem z szablonem i zdarzeniami DOM. Pod względem zakresu są to testy integracyjne komponentów. Nie uruchamialiśmy pełnej aplikacji z routingiem, backendem i przepływem użytkownika. Sam Browser Mode nie zmienia takiego testu w test E2E.

W S1–S3 jsdom wystarczył do sprawdzenia zadanego zachowania. W S4–S5 komponent potrzebował wymiarów i powiadomień przeglądarki, a w S6 trzeba było sprawdzić możliwość kliknięcia. Osobne testy jednostkowe w tych scenariuszach mogą sprawdzać walidator, wybór stanu na podstawie szerokości lub obliczanie pozycji. Są przydatne, ale nie potwierdzają interakcji komponentu z przeglądarką. Do sprawdzenia przepływu całej aplikacji potrzebne byłyby testy E2E; eksperyment nie badał tego poziomu.

S1–S3: formularz, fokus i Tab

W S1 formularz odrzucał bad.example, wyświetlał błąd i utrzymywał licznik wysłań na poziomie zera. Następnie przyjmował **@*****le.com. Mutacja usuwała sprawdzenie formatu, pozostawiając sprawdzenie pustego pola. Wykryły ją wszystkie trzy tryby. Walidację wykonywała aplikacja z novalidate; natywny komunikat przeglądarki nie należał do scenariusza.

W S2 sprawdzaliśmy fokus: po otwarciu dialogu i ustabilizowaniu renderowania miał trafić na Zamknij, a po zamknięciu wrócić na Otwórz. Mutacja usuwała przeniesienie fokusu przy otwieraniu. Sprawdzenie document.activeElement wykryło ją w A, B i C.

W S3 test trzykrotnie naciskał Tab ze znanej pozycji początkowej. Oczekiwana kolejność: Pierwszy, Drugi, Koniec. Między dwiema ostatnimi kontrolkami znajdowała się jeszcze jedna w sekcji z display: none. Po zamianie tej właściwości na opacity: 0 kontrolka pozostawała w kolejności Tab, choć wizualnie była ukryta. Zmianę wykryły zarówno user-event.tab w jsdom, jak i akcja przeglądarkowa.

Te testy nie wymagały pomiarów layoutu. Ich wyniki dotyczą programowego fokusu i wskazanej sekwencji Tab. Nie sprawdzaliśmy focus trap, visibility: hidden, inert ani pozostałych wariantów nawigacji klawiaturą. Komponent używający tych sposobów ograniczania interakcji wymaga osobnych testów kolejności Tab i fokusu. S3 nie jest pełnym testem dostępności.

S4: który kontener obserwuje ResizeObserver

Komponent zmieniał etykietę w zależności od szerokości swojego kontenera. Przy 360 px pokazywał Szeroki. Po zwężeniu do 240 px, poniżej progu 300 px, miał pokazać Wąski. Viewport się nie zmieniał, a zewnętrzny kontener nadal miał szerokość 400 px.

W poprawnej implementacji ResizeObserver obserwował wewnętrzny kontener. Mutacja przełączała go na zewnętrzny. Właściwa szerokość się zmieniała, ale observer śledził inny element.

W komponencie Angulara powiadomienie aktualizowało sygnał, którego wartość pojawiała się w szablonie. Fragment poprawnej implementacji:

this.observer = new ResizeObserver((entries) => {
  this.compact.set(entries[0].contentRect.width < 300);
});
this.observer.observe(this.inner.nativeElement);

Przy niszczeniu komponentu observer był odłączany. W kodzie źródłowym istniał już osobny hook:

ngOnDestroy(): void {
  this.observer?.disconnect();
}

Ręczne przekazanie callbackowi szerokości 240 px pozwala sprawdzić, czy przełącza on stan komponentu. Jednak w takim teście powiadomienie zostało już dostarczone niezależnie od tego, który element obserwuje przeglądarka. Bez osobnego sprawdzenia obserwowanego obiektu takie zastąpienie zachowania nie sprawdza błędu z naszego scenariusza.

Można też napisać bardziej precyzyjny test z mockiem: zapisać argument observe() i porównać go z wewnętrznym kontenerem. Taki spy mógłby wykryć właśnie tę mutację w jsdom. Sprawdzałby, który element komponent zaczął obserwować. To przydatna kontrola implementacji, ale nie potwierdza całego scenariusza użytkownika: po rzeczywistym zwężeniu kontenera przeglądarka dostarczyła powiadomienie, a etykieta się zaktualizowała. Taki spy nie należał do głównej serii.

W B i C rzeczywiście zwężaliśmy wewnętrzny kontener i czekaliśmy na zmianę etykiety. Oba testy wykryły mutację. Dla A pełny scenariusz miał status unsupported: w tym przykładzie brakowało niezależnych pomiarów layoutu i powiadomienia przeglądarki.

S5: gdzie znalazł się popover

Komponent otwierał popover obok triggera, czyli elementu, do którego był zakotwiczony. W zwykłym położeniu popover miał znajdować się po prawej stronie. Gdy trigger przesuwał się przy prawą krawędź, do left = 740 przy viewporcie 800 × 600 CSS px, popover miał otwierać się po lewej.

Sprawdzaliśmy stronę oraz cały interaktywny prostokąt względem viewportu, z tolerancją jednego piksela. Mutacja wyłączała zmianę strony. Zwykłe otwarcie nadal działało, ale przy krawędzi prawa granica popovera sięgała 948 px.

Po poprawieniu testów B i C wykryły naruszenie. W A pełny scenariusz miał status unsupported: wymagał pomiaru rzeczywistego położenia popovera.

Dlaczego pierwszy test przeglądarkowy przeszedł mimo błędu

Po otwarciu Angular dodawał popover do DOM, a jego położenie było obliczane później przez requestAnimationFrame. W tym czasie element już istniał, ale zachowywał współrzędne poprzedniego otwarcia. Test mógł sprawdzić ten stary prostokąt i przejść na wadliwej wersji.

Poprawialiśmy oczekiwanie w dwóch krokach. Najpierw zaczęliśmy czekać na przesunięcie triggera do krawędzi przed otwarciem. To nie wystarczyło: trzeba było także poczekać na aktualizację położenia samego popovera. Dopiero potem test sprawdzał stronę i wszystkie cztery granice viewportu.

Oczekiwanie na aktualizację dopuszczało zarówno poprawne, jak i błędne nowe położenie. Nie podpowiadało więc testowi oczekiwanej odpowiedzi. Błąd wykrywały późniejsze asercje dotyczące strony i granic.

Przeglądarka dostarczała rzeczywiste współrzędne, ale nasz test odczytywał je za wcześnie. Po poprawieniu oczekiwań i uzupełnieniu asercji powtórzyliśmy końcowe serie. Wczesne fałszywe przejścia zachowaliśmy w dzienniku odstępstw i wykluczyliśmy z macierzy.

fixture.detectChanges();
await fixture.whenStable();

open(): void {
  this.opened.set(true);
  requestAnimationFrame(() => this.place());
}

await user.click(buttons[0]);
await until(() => Math.round(trigger.getBoundingClientRect().left) === 740);
await user.click(trigger);
await until(() => popup().left >= 500);

expect(popup().right).toBeLessThan(trigger.getBoundingClientRect().left);
expect(popup().left).toBeGreaterThanOrEqual(-1);
expect(popup().right).toBeLessThanOrEqual(801);
expect(popup().top).toBeGreaterThanOrEqual(-1);
expect(popup().bottom).toBeLessThanOrEqual(601);

S6: trzy sposoby sprawdzenia zasłoniętego przycisku

Widoczny przycisk Potwierdź o wymiarach 160 × 48 px miał po jednym kliknięciu wskaźnikiem w środku zmieniać status z Oczekuje na Potwierdzono. Fragmenty kodu zachowują oryginalne rosyjskie etykiety przykładu: Подтвердить (Potwierdź), Ожидает (Oczekuje) i Подтверждено (Potwierdzono).

Środek zasłaniała warstwa dekoracyjna. W poprawnej wersji miała pointer-events: none. Mutacja zmieniała wartość na auto: przycisk i handler pozostawały takie same, ale warstwa przechwytywała kliknięcia.

Pierwotny test A/B:

const fixture = await mount(CoveredButtonComponent);
const button = fixture.nativeElement.querySelector('button') as HTMLButtonElement;
const output = fixture.nativeElement.querySelector('output') as HTMLOutputElement;
expect(output.textContent?.trim()).toBe('Ожидает');
await userEvent.setup().click(button);
await until(() => output.textContent?.trim() === 'Подтверждено');

Tutaj userEvent jest importowany z @testing-library/user-event. Handler się uruchamiał i status zmieniał się także w wadliwej wersji. Dlatego pierwotne A/S6 i B/S6 otrzymały partial.

user-event modeluje sekwencje interakcji i wykonuje własne sprawdzenia. Jego pointerEventsCheck sprawdza, czy element ma lub dziedziczy pointer-events: none. Testing Library: pointerEventsCheck. Osobno dokumentacja pointer API mówi, że biblioteka nie ustala, czy opisane działanie jest możliwe we wskazanym punkcie layoutu. Testing Library: pointer.

Sam przycisk w S6 nie miał pointer-events: none. Problemem była inna warstwa nad nim. Target przekazany do click nadal był przyciskiem, a test po akcji sprawdzał tylko zmianę statusu. Nawet prawdziwy Chromium nie dodawał do tego kodu kontroli trafienia wskaźnikiem.

Provider click

W C akcja korzystała z page z vitest/browser. Odpowiedni fragment:

const fixture = await mount(CoveredButtonComponent);
const output = fixture.nativeElement.querySelector('output') as HTMLOutputElement;
expect(output.textContent?.trim()).toBe('Ожидает');
await page.getByRole('button', { name: 'Подтвердить' }).click();
await until(() => output.textContent?.trim() === 'Подтверждено');

Click był wywoływany bez force. Poprawna wersja przechodziła test. Na wadliwej provider zgłaszał, że .decoration przechwytuje pointer events, i nie mógł wykonać akcji. Sprawdzenie actionability wykrywało przeszkodę przed kliknięciem.

Osobny test B z elementFromPoint

Po głównej serii dodaliśmy eksploracyjne sprawdzenie B z document.elementFromPoint. Metoda zwraca najwyższy element w danym punkcie. Środek wyliczaliśmy z rzeczywistego prostokąta przycisku. Poniżej funkcja z tego testu:

const hitAtCentre = () => {
  const rect = button.getBoundingClientRect();
  expect(rect.width).toBeGreaterThan(0);
  expect(rect.height).toBeGreaterThan(0);
  const x = rect.left + rect.width / 2;
  const y = rect.top + rect.height / 2;
  const target = document.elementFromPoint(x, y);
  return { x, y, target, hitButton: target === button || button.contains(target) };
};

Sprawdzenie wykonywaliśmy przed syntetycznym clickiem i po nim. W poprawnej wersji w środku (80, 24) znajdował się przycisk lub jego potomek. W wadliwej metoda zwracała .decoration, choć handler nadal zmieniał status. Test wymagał hitButton: true w obu pomiarach i wykrył zasłonięcie.

W B były teraz dwa różne testy. Pierwotny sprawdzał tylko zmianę statusu po syntetycznym clicku. Późniejszy dodatkowo pytał, który element znajduje się w punkcie kliknięcia, i wykrywał zasłonięcie.

Główna tabela opisuje pierwszy zestaw testów. Dlatego B/S6 pozostaje w niej partial, a wynik dodanego testu podajemy osobno. To nie jest ograniczenie Browser Mode: przeglądarka dostarczała dane do hit testu, ale pierwotny test o nie nie pytał. Sprawdzenie jednego punktu nie jest też równoważne pełnemu zestawowi sprawdzeń actionability providera.

W tym scenariuszu środowisko dostarczało informacje o geometrii, akcja określała sposób interakcji, a test oracle definiował, jaki wynik uznać za poprawny. Zmiana statusu wystarczała do sprawdzenia handlera, ale nie do potwierdzenia deklarowanego kliknięcia wskaźnikiem.

Jak sprawdzić własny test

Poszukaj błędu, z którym Twój test nadal pozostanie zielony:

Dla formularza, programowego fokusu i konkretnej kolejności Tab najpierw sprawdź, czy istniejący test w jsdom ma wystarczające obserwacje. W scenariuszu klawiaturowym wykonuj sekwencję Tab: wywołania .focus() na oczekiwanych elementach nie sprawdzają przejść.

Gdy wymaganie zależy od rzeczywistego rozmiaru, położenia lub powiadomienia przeglądarki, sprawdź te dane w przeglądarce. Mock może uzupełniać takie sprawdzenie testem logiki. Nazwa i opis testu powinny odzwierciedlać tę część zachowania, którą potwierdza.

Każdy wybrany błąd sprawdzaj razem z poprawną wersją. Jeśli obie nie przechodzą testu, najpierw trzeba zbadać test i jego warunki.

Warunki eksperymentu

Testy uruchamialiśmy na Windows 11. Dla B i C używaliśmy Chromium w trybie headless z viewportem 800 × 600 CSS px i współczynnikiem skali 1.

Sami wybraliśmy sześć błędów i sprawdziliśmy je na małym przykładzie. Wyniki wyjaśniają, co sprawdzają te testy. Nie mówią, jak często takie błędy występują w działających aplikacjach ani ile błędów to samo podejście znajdzie w innym projekcie. Nie uruchamialiśmy testów na innych systemach operacyjnych ani silnikach przeglądarek. Nie sprawdzaliśmy też dużych zestawów testów ani przepływów E2E.

Na podstawie tych materiałów nie można porównywać szybkości: stare lokalne uruchomienia wykonywały różną ilość pracy. Nie mierzyliśmy pamięci, działania w CI ani kosztów migracji. Nie wyciągamy też wniosków o flakiness. Jedno wczesne uruchomienie S4/S5 na zimno zakończyło się przekroczeniem limitu czasu; nie ustaliliśmy przyczyny.

Przed napisaniem artykułu sprawdziliśmy zapisane wyniki i logi. Nie było niezależnego powtórzenia na innej maszynie z czystą instalacją.

Wniosek

W pierwotnych testach A/B dla S6 handler się uruchamiał, a zasłonięty przycisk przechodził test. Zasłonięcie wykryliśmy, gdy zaczęliśmy sprawdzać możliwość kliknięcia. Od tego warto zacząć wybór środowiska: co użytkownik musi móc zrobić i jaka obserwacja w teście to potwierdza?