Mejorando el Rendimiento

Aislamiento de pruebas

Por defecto, Vitest ejecuta cada archivo de prueba en un entorno aislado basado en el pool configurado:

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

Este aislamiento puede aumentar considerablemente la duración de las pruebas, lo cual podría no ser deseable para proyectos que no dependen de efectos secundarios y gestionan correctamente su estado (lo que suele ser el caso en un entorno node). En tales situaciones, deshabilitar el aislamiento mejorará la velocidad de las pruebas. Para ello, puede pasar el flag --no-isolate a la CLI o establecer la propiedad test.isolate en la configuración a false.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    isolate: false,
    // También puedes deshabilitar el aislamiento solo para pools específicos
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

Si está utilizando el pool vmThreads, no es posible deshabilitar el aislamiento. Considere usar el pool threads en su lugar para mejorar el rendimiento de sus pruebas.

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

CLI

vitest --no-file-parallelism

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Pool

Por defecto, Vitest ejecuta las pruebas en pool: 'forks'. Si bien el pool 'forks' es mejor para resolver problemas de compatibilidad (como procesos colgados y fallos de segmentación), puede ser ligeramente más lento que pool: 'threads' en proyectos más grandes.

Puede intentar mejorar 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 (Sharding)

La fragmentación de pruebas es un proceso que consiste en dividir su suite de pruebas en grupos, o fragmentos (shards). Esto puede ser útil cuando tiene una suite de pruebas grande y varias máquinas que pueden ejecutar subconjuntos de esa suite simultáneamente.

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

vitest run --reporter=blob --shard=1/3 # primera máquina
vitest run --reporter=blob --shard=2/3 # segunda máquina
vitest run --reporter=blob --shard=3/3 # tercera máquina

Vitest divide sus archivos de prueba, no sus casos de prueba individuales, en fragmentos. Si tiene 1000 archivos de prueba, la opción --shard=1/4 ejecutará 250 archivos de prueba, sin importar cuántos casos de prueba individuales contengan.

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

vitest run --merge-reports

Github action example

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@a7487c7e89a18df4991f7f222e4898a00d66ddda # v4.1.0

      - 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@a7487c7e89a18df4991f7f222e4898a00d66ddda # v4.1.0

      - 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 una gran cantidad de CPU.

Vitest ejecutará un solo servidor Vite en su hilo principal. Los demás hilos se utilizan para ejecutar archivos de prueba. En una máquina con 32 CPU, por ejemplo, el hilo principal es responsable de manejar la carga proveniente de 31 hilos de prueba.

Para reducir la carga del servidor Vite del hilo principal, puede usar la fragmentación de pruebas. La carga se puede equilibrar entre múltiples servidores Vite.

# Ejemplo para dividir pruebas en 32 CPU en 4 fragmentos.
# Como cada proceso necesita 1 hilo principal, hay 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 run --merge-reports