Mejorando el Rendimiento

Aislamiento de pruebas

Por defecto, Vitest ejecuta cada archivo de prueba en un entorno aislado, basándose en el grupo configurado:

• El grupo threads ejecuta cada archivo de prueba en un Worker distinto.
• El grupo forks ejecuta cada archivo de prueba en un proceso hijo bifurcado separado.
• El grupo vmThreads ejecuta cada archivo de prueba en un contexto de VM separado, pero utiliza workers para el paralelismo.

Este aislamiento puede incrementar significativamente la duración de las pruebas, lo cual podría no ser deseable para proyectos que no dependen de efectos secundarios y gestionan correctamente la limpieza de su estado (lo que suele ser el caso en entornos node). En tales situaciones, deshabilitar el aislamiento puede mejorar la velocidad de las pruebas. Para ello, puede usar la opción --no-isolate en la CLI o establecer la propiedad test.isolate en false en la configuración. Si está utilizando varios grupos a la vez con poolMatchGlobs, también puede deshabilitar el aislamiento para un grupo específico.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    isolate: false,
    // también se puede deshabilitar el aislamiento solo para grupos específicos
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

Si está utilizando el grupo vmThreads, no es posible deshabilitar el aislamiento. Para mejorar el rendimiento de sus pruebas en este escenario, considere usar el grupo threads en su lugar.

Para algunos proyectos, también podría ser beneficioso deshabilitar el paralelismo para mejorar el tiempo de inicio. Para hacerlo, proporcione la opción --no-file-parallelism a la CLI o establezca la propiedad test.fileParallelism en false en la configuración.

CLI

vitest --no-file-parallelism

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    fileParallelism: false,
  },
});

Grupo

Por defecto, Vitest ejecuta las pruebas en pool: 'forks'. Aunque el grupo 'forks' ofrece mejor compatibilidad para problemas como procesos colgados y fallos de segmentación, puede resultar ligeramente más lento que pool: 'threads' en proyectos de mayor tamaño.

Puede intentar reducir el tiempo de ejecución de las pruebas cambiando la opción pool en la configuración:

CLI

vitest --pool=threads

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    pool: 'threads',
  },
});

Fragmentación

La fragmentación de pruebas (test sharding) implica ejecutar un pequeño subconjunto de casos de prueba a la vez. Esto puede ser útil cuando se dispone de varias máquinas que pueden utilizarse para ejecutar pruebas simultáneamente.

Para dividir las pruebas de Vitest en múltiples ejecuciones, use la opción --shard junto con la opción --reporter=blob:

vitest run --reporter=blob --shard=1/3 # 1.ª máquina
vitest run --reporter=blob --shard=2/3 # 2.ª máquina
vitest run --reporter=blob --shard=3/3 # 3.ª máquina

Recoja los resultados guardados en el directorio .vitest-reports de cada máquina y fusiónelos con la opción --merge-reports:

vitest --merge-reports

Ejemplo de Acción de GitHub

Esta configuración también se utiliza en https://github.com/vitest-tests/test-sharding.

# Inspirado en https://playwright.dev/docs/test-sharding
name: Tests
on:
  push:
    branches:
      - main
jobs:
  tests:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shardIndex: [1, 2, 3, 4]
        shardTotal: [4]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install pnpm
        uses: pnpm/action-setup@v4

      - name: Install dependencies
        run: pnpm i

      - name: Run tests
        run: pnpm run test --reporter=blob --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}

      - name: Upload blob report to GitHub Actions Artifacts
        if: ${{ !cancelled() }}
        uses: actions/upload-artifact@v4
        with:
          name: blob-report-${{ matrix.shardIndex }}
          path: .vitest-reports/*
          include-hidden-files: true
          retention-days: 1

  merge-reports:
    if: ${{ !cancelled() }}
    needs: [tests]

    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install pnpm
        uses: pnpm/action-setup@v4

      - name: Install dependencies
        run: pnpm i

      - name: Download blob reports from GitHub Actions Artifacts
        uses: actions/download-artifact@v4
        with:
          path: .vitest-reports
          pattern: blob-report-*
          merge-multiple: true

      - name: Merge reports
        run: npx vitest --merge-reports

TIP

La fragmentación de pruebas también puede ser útil en máquinas con un alto número de CPU.

Vitest ejecutará un único servidor Vite en su hilo principal. Los hilos restantes se utilizan para ejecutar archivos de prueba. En una máquina con un alto número de CPU, el hilo principal puede convertirse en un cuello de botella, ya que podría no ser capaz de manejar todas las solicitudes provenientes de los hilos de prueba. Por ejemplo, en una máquina con 32 CPU, el hilo principal es responsable de gestionar la carga generada por 31 hilos de prueba.

Para reducir la carga del servidor Vite en el hilo principal, puede usar la fragmentación de pruebas. La carga se puede distribuir entre varios servidores Vite.

# Ejemplo para dividir pruebas en 32 CPU en 4 fragmentos.
# Como cada proceso necesita 1 hilo principal, quedan 7 hilos para los ejecutores de pruebas (1+7)*4 = 32
# Use VITEST_MAX_THREADS o VITEST_MAX_FORKS dependiendo del pool:
VITEST_MAX_THREADS=7 vitest run --reporter=blob --shard=1/4 & \
VITEST_MAX_THREADS=7 vitest run --reporter=blob --shard=2/4 & \
VITEST_MAX_THREADS=7 vitest run --reporter=blob --shard=3/4 & \
VITEST_MAX_THREADS=7 vitest run --reporter=blob --shard=4/4 & \
wait # https://man7.org/linux/man-pages/man2/waitpid.2.html

vitest --merge-reports