Sharding

Domyślnie, WebdriverIO uruchamia testy równolegle i dąży do optymalnego wykorzystania rdzeni procesora na Twoim komputerze. Aby osiągnąć jeszcze większe zrównoleglenie, możesz dodatkowo skalować wykonywanie testów WebdriverIO poprzez uruchamianie testów na wielu maszynach jednocześnie. Ten tryb działania nazywamy "shardingiem".

Dzielenie testów między wieloma maszynami

Aby podzielić zestaw testów, przekaż --shard=x/y do wiersza poleceń. Na przykład, aby podzielić zestaw na cztery części, każda uruchamiająca jedną czwartą testów:

npx wdio run wdio.conf.js --shard=1/4
npx wdio run wdio.conf.js --shard=2/4
npx wdio run wdio.conf.js --shard=3/4
npx wdio run wdio.conf.js --shard=4/4

Teraz, jeśli uruchomisz te części równolegle na różnych komputerach, twój zestaw testów zakończy się cztery razy szybciej.

Przykład GitHub Actions

GitHub Actions obsługuje dzielenie testów między wieloma zadaniami za pomocą opcji jobs.<job_id>.strategy.matrix. Opcja matrix uruchomi osobne zadanie dla każdej możliwej kombinacji dostarczonych opcji.

Poniższy przykład pokazuje, jak skonfigurować zadanie do uruchamiania testów na czterech maszynach równolegle. Pełną konfigurację pipeline'u można znaleźć w projekcie Cucumber Boilerplate.

• Najpierw dodajemy opcję matrix do konfiguracji naszego zadania z opcją shard zawierającą liczbę fragmentów, które chcemy utworzyć. shard: [1, 2, 3, 4] utworzy cztery fragmenty, każdy z innym numerem fragmentu.
• Następnie uruchamiamy nasze testy WebdriverIO z opcją --shard ${{ matrix.shard }}/${{ strategy.job-total }}. To będzie nasze polecenie testowe dla każdego fragmentu.
• Na koniec przesyłamy nasz raport dziennika wdio do GitHub Actions Artifacts. Dzięki temu logi będą dostępne w przypadku niepowodzenia fragmentu.

Pipeline testowy jest zdefiniowany następująco:

name: Test

on: [push, pull_request]

jobs:
    lint:
        # ...
    unit:
        # ...
    e2e:
        name: 🧪 Test (${{ matrix.shard }}/${{ strategy.job-total }})
        runs-on: ubuntu-latest
        needs: [lint, unit]
        strategy:
            matrix:
                shard: [1, 2, 3, 4]
        steps:
            - uses: actions/checkout@v4
            - uses: ./.github/workflows/actions/setup
            - name: E2E Test
              run: npm run test:features -- --shard ${{ matrix.shard }}/${{ strategy.job-total }}
            - uses: actions/upload-artifact@v1
              if: failure()
              with:
                  name: logs-${{ matrix.shard }}
                  path: logs

Spowoduje to równoległe uruchomienie wszystkich fragmentów, skracając czas wykonania testów 4-krotnie:

Zobacz commit 96d444e z projektu Cucumber Boilerplate, który wprowadził sharding do swojego pipeline'u testowego, co pomogło zmniejszyć ogólny czas wykonania z 2:23 min do 1:30 min, redukcja o 37% 🎉.