Testowanie Komponentów

Dzięki Browser Runner WebdriverIO możesz uruchamiać testy w rzeczywistej przeglądarce stacjonarnej lub mobilnej, używając WebdriverIO i protokołu WebDriver do automatyzacji i interakcji z tym, co jest renderowane na stronie. To podejście ma wiele zalet w porównaniu do innych frameworków testowych, które pozwalają testować tylko na JSDOM.

Jak to działa?

Browser Runner używa Vite do renderowania strony testowej i inicjalizacji frameworka testowego do uruchamiania testów w przeglądarce. Obecnie obsługuje tylko Mocha, ale Jasmine i Cucumber są w planach. Pozwala to testować dowolne rodzaje komponentów, nawet w projektach, które nie używają Vite.

Serwer Vite jest uruchamiany przez testrunner WebdriverIO i skonfigurowany tak, aby można było używać wszystkich reporterów i usług, tak jak w przypadku normalnych testów e2e. Ponadto inicjalizuje instancję browser, która umożliwia dostęp do podzbioru API WebdriverIO w celu interakcji z dowolnymi elementami na stronie. Podobnie jak w przypadku testów e2e, możesz uzyskać dostęp do tej instancji poprzez zmienną browser dołączoną do globalnego zakresu lub importując ją z @wdio/globals, w zależności od ustawienia injectGlobals.

WebdriverIO ma wbudowane wsparcie dla następujących frameworków:

• Nuxt: Testrunner WebdriverIO wykrywa aplikację Nuxt i automatycznie konfiguruje composables projektu oraz pomaga zamockować backend Nuxt, więcej informacji w dokumentacji Nuxt
• TailwindCSS: Testrunner WebdriverIO wykrywa, czy używasz TailwindCSS i poprawnie ładuje środowisko na stronę testową

Konfiguracja

Aby skonfigurować WebdriverIO do testowania jednostkowego lub komponentowego w przeglądarce, zainicjuj nowy projekt WebdriverIO za pomocą:

npm init wdio@latest ./
# lub
yarn create wdio ./

Po uruchomieniu kreatora konfiguracji wybierz browser do uruchamiania testów jednostkowych i komponentowych oraz wybierz jeden z presetów, jeśli chcesz, lub wybierz "Other", jeśli chcesz uruchamiać tylko podstawowe testy jednostkowe. Możesz również skonfigurować niestandardową konfigurację Vite, jeśli już używasz Vite w swoim projekcie. Więcej informacji znajdziesz we wszystkich opcjach runnera.

informacja

Uwaga: WebdriverIO domyślnie uruchamia testy przeglądarkowe w CI w trybie headless, np. gdy zmienna środowiskowa CI jest ustawiona na '1' lub 'true'. Możesz ręcznie skonfigurować to zachowanie za pomocą opcji headless dla runnera.

Na końcu tego procesu powinieneś znaleźć plik wdio.conf.js zawierający różne konfiguracje WebdriverIO, w tym właściwość runner, np.:

wdio.comp.conf.js

loading...

View on GitHub

Definiując różne capabilities, możesz uruchamiać testy w różnych przeglądarkach, równolegle, jeśli chcesz.

Jeśli nadal nie jesteś pewien, jak wszystko działa, obejrzyj poniższy tutorial o tym, jak rozpocząć Testowanie Komponentów w WebdriverIO:

Test Harness

To całkowicie od ciebie zależy, co chcesz uruchamiać w swoich testach i jak chcesz renderować komponenty. Jednakże zalecamy używanie Testing Library jako framework narzędziowy, ponieważ zapewnia on wtyczki dla różnych frameworków komponentów, takich jak React, Preact, Svelte i Vue. Jest bardzo przydatny do renderowania komponentów na stronie testowej i automatycznie czyści te komponenty po każdym teście.

Możesz dowolnie mieszać prymitywy Testing Library z komendami WebdriverIO, np.:

component-testing/svelte-example.js

loading...

View on GitHub

Uwaga: używanie metod renderowania z Testing Library pomaga usunąć utworzone komponenty między testami. Jeśli nie używasz Testing Library, upewnij się, że dołączasz swoje komponenty testowe do kontenera, który jest czyszczony między testami.

Skrypty konfiguracyjne

Możesz skonfigurować swoje testy, uruchamiając dowolne skrypty w Node.js lub w przeglądarce, np. wstrzykiwanie stylów, mockowanie API przeglądarki lub łączenie się z usługą zewnętrzną. Hooki hooks WebdriverIO mogą być używane do uruchamiania kodu w Node.js, podczas gdy mochaOpts.require pozwala importować skrypty do przeglądarki przed załadowaniem testów, np.:

export const config = {
    // ...
    mochaOpts: {
        ui: 'tdd',
        // podaj skrypt konfiguracyjny do uruchomienia w przeglądarce
        require: './__fixtures__/setup.js'
    },
    before: () => {
        // skonfiguruj środowisko testowe w Node.js
    }
    // ...
}

Na przykład, jeśli chcesz zamockować wszystkie wywołania fetch() w swoim teście za pomocą następującego skryptu konfiguracyjnego:

import { fn } from '@wdio/browser-runner'

// uruchom kod przed załadowaniem wszystkich testów
window.fetch = fn()

export const mochaGlobalSetup = () => {
    // uruchom kod po załadowaniu pliku testowego
}

export const mochaGlobalTeardown = () => {
    // uruchom kod po wykonaniu pliku specyfikacji
}

Teraz w swoich testach możesz dostarczyć niestandardowe wartości odpowiedzi dla wszystkich żądań przeglądarki. Przeczytaj więcej o globalnych fiksturach w dokumentacji Mocha.

Obserwowanie plików testowych i aplikacyjnych

Istnieje wiele sposobów debugowania testów przeglądarkowych. Najłatwiejszym jest uruchomienie testtunnera WebdriverIO z flagą --watch, np.:

$ npx wdio run ./wdio.conf.js --watch

Spowoduje to początkowe uruchomienie wszystkich testów i zatrzymanie po ich wykonaniu. Możesz wtedy wprowadzać zmiany w poszczególnych plikach, które zostaną ponownie uruchomione indywidualnie. Jeśli ustawisz filesToWatch wskazujący na pliki twojej aplikacji, wszystkie testy zostaną ponownie uruchomione po wprowadzeniu zmian w aplikacji.

Debugowanie

Chociaż (jeszcze) nie jest możliwe ustawienie punktów przerwania w twoim IDE i ich rozpoznawanie przez zdalną przeglądarkę, możesz użyć komendy debug, aby zatrzymać test w dowolnym momencie. Pozwala to otworzyć DevTools, aby następnie debugować test, ustawiając punkty przerwania w zakładce sources.

Gdy komenda debug zostanie wywołana, otrzymasz również interfejs repl Node.js w terminalu, mówiący:

The execution has stopped!
You can now go into the browser or use the command line as REPL
(To exit, press ^C again or type .exit)

Naciśnij Ctrl lub Command + c lub wprowadź .exit, aby kontynuować test.

Uruchamianie za pomocą Selenium Grid

Jeśli masz skonfigurowany Selenium Grid i uruchamiasz przeglądarkę przez tę sieć, musisz ustawić opcję host dla runnera przeglądarki, aby umożliwić przeglądarce dostęp do odpowiedniego hosta, na którym są serwowane pliki testowe, np.:

export const config: WebdriverIO.Config = {
    runner: ['browser', {
        // adres IP sieciowy maszyny uruchamiającej proces WebdriverIO
        host: 'http://172.168.0.2'
    }]
}

Zapewni to, że przeglądarka poprawnie otworzy właściwą instancję serwera hostowaną na instancji uruchamiającej testy WebdriverIO.

Przykłady

Możesz znaleźć różne przykłady testowania komponentów przy użyciu popularnych frameworków komponentów w naszym repozytorium przykładów.