Featured image of post Pruebas frontales eficientes con Vitest y Testing LibraryFeatured image of post Pruebas frontales eficientes con Vitest y Testing Library

Pruebas frontales eficientes con Vitest y Testing Library

Mayor velocidad de desarrollo gracias al entorno de prueba nativo de Vite

Jest ha sido la corriente principal para las pruebas de front-end durante muchos años, pero su complejidad de configuración y sus gastos generales fueron problemas. Al combinar “Vitest” y “React Testing Library”, que comparten la configuración de Vite, puede obtener un entorno de prueba extremadamente rápido.

Hemos resumido principios prácticos para crear conjuntos de pruebas que sean fáciles de mantener y difíciles de romper.


Principio: Pruebe el “comportamiento del usuario”, no los “detalles de implementación”

Probar directamente el estado interno de un componente da como resultado pruebas frágiles que se rompen con cada refactorización. La idea básica es verificar el comportamiento de la pantalla tal como se muestra al usuario.

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { LoginForm } from './LoginForm';

test('入力からログイン完了までのフローを検証', async () => {
  const user = userEvent.setup();
  render(<LoginForm />);

  await user.type(screen.getByLabelText('メールアドレス'), 'test@example.com');
  await user.click(screen.getByRole('button', { name: 'ログイン' }));

  expect(await screen.findByText('ようこそ')).toBeInTheDocument();
});

Errores en las actualizaciones asincrónicas: uso adecuado de las funciones de consulta

  • getBy*: Validación síncrona de que el elemento “existe ahora”. Error inmediato si no está presente.
  • findBy*: Espere los elementos que se “muestran asincrónicamente con un retraso”, como la adquisición de API (devuelve una Promesa).
  • queryBy*: Se utiliza para afirmar que el elemento “no existe en la pantalla” (devuelve nulo).

Puntos de paralelización para reducir el tiempo de ejecución de CI

Vitest utiliza la ejecución paralela de subprocesos de forma predeterminada. Para las pruebas que involucran manipulación de DOM, restablezca adecuadamente los simulacros en “afterEach” para mantener la independencia para cada caso de prueba, maximizar la cantidad de pruebas paralelas y reducir los costos de CI.