Skip to content
Vitest 3
Main Navigation Guía & APIConfiguraciónModo NavegadorAPI avanzada
3.2.0
2.1.9
1.6.1
0.34.6

Español

English
简体中文
繁體中文
Français
Русский
Português – Brasil
Deutsch
日本語
한국어
Italiano
Polski
Türkçe
čeština
magyar

Español

English
简体中文
繁體中文
Français
Русский
Português – Brasil
Deutsch
日本語
한국어
Italiano
Polski
Türkçe
čeština
magyar

Apariencia

Sidebar Navigation

Introducción

Por qué Vitest

Primeros pasos

Características

Configuración de Vitest

API

Referencia de la API de prueba

Funciones de Simulación

Vi

expect

expectTypeOf

assert

assertType

Guía

Interfaz de línea de comandos

Filtrado de Tests

Proyectos de prueba

Reportes

Cobertura

Instantáneas

Simulación (Mocking)

Paralelismo

Pruebas de Tipado

Interfaz de usuario de Vitest

Pruebas en el código fuente

Contexto de prueba

Anotaciones de prueba

Entorno de pruebas

Extender Matchers

Integraciones con IDE

Depuración

Errores comunes

Guía de migración

Migración a Vitest 3.0

Migración desde Jest

Rendimiento

Perfilado del rendimiento de las pruebas

Mejorando el Rendimiento

Modo Navegador

API Avanzadas

Comparaciones con otros ejecutores de pruebas

En esta página

Pruebas de Tipado ​

Proyecto de Ejemplo

GitHub - Probar en Línea

Vitest te permite escribir pruebas para tus tipos utilizando las sintaxis expectTypeOf o assertType. Por defecto, todos los archivos *.test-d.ts se consideran pruebas de tipo, pero puedes modificar esta configuración con la opción typecheck.include.

Internamente, Vitest invoca a tsc o vue-tsc (según tu configuración) y analiza sus resultados. Vitest también mostrará los errores de tipo encontrados en tu código fuente. Puedes deshabilitar esta funcionalidad con la opción de configuración typecheck.ignoreSourceErrors.

Es importante tener en cuenta que Vitest no ejecuta estos archivos; solo son analizados estáticamente por el compilador. Esto implica que si utilizas nombres dinámicos, test.each o test.for, el nombre de la prueba no se evaluará, sino que se mostrará literalmente.

WARNING

Antes de Vitest 2.1, la opción typecheck.include sobrescribía el patrón include, lo que significaba que tus pruebas en tiempo de ejecución no se ejecutaban; solo se verificaban los tipos.

A partir de Vitest 2.1, si tus patrones include y typecheck.include se superponen, Vitest reportará las pruebas de tipo y las pruebas en tiempo de ejecución como entradas separadas.

El uso de opciones de línea de comandos (CLI), como --allowOnly y -t, también es compatible para la verificación de tipos.

ts
import { assertType, expectTypeOf } from 'vitest';
import { mount } from './mount.js';

test('mis tipos funcionan como se espera', () => {
  expectTypeOf(mount).toBeFunction();
  expectTypeOf(mount).parameter(0).toMatchTypeOf<{ name: string }>();

  // @ts-expect-error name es un string
  assertType(mount({ name: 42 }));
});

Cualquier error de tipo que se active dentro de un archivo de prueba será tratado como un error de prueba. Esto te permite utilizar cualquier técnica de tipado que desees para probar los tipos de tu proyecto.

Puedes consultar una lista de posibles comparadores en la sección de API.

Lectura de Errores ​

Si estás utilizando la API expectTypeOf, consulta la documentación de expect-type sobre sus mensajes de error.

Cuando los tipos no coinciden, .toEqualTypeOf y .toMatchTypeOf emplean un tipo auxiliar especial para generar mensajes de error lo más útiles posible. Sin embargo, su interpretación tiene un matiz. Dado que las aserciones se escriben de forma encadenada, el fallo debe residir en el tipo "esperado", no en el tipo "real" (expect<Actual>().toEqualTypeOf<Expected>()). Esto puede hacer que los errores de tipo sean un poco confusos, por lo que esta biblioteca produce un tipo MismatchInfo para intentar hacer explícita la expectativa. Por ejemplo:

ts
expectTypeOf({ a: 1 }).toEqualTypeOf<{ a: string }>();

Esta aserción fallará, ya que {a: 1} tiene el tipo {a: number} y no {a: string}. El mensaje de error en este caso dirá algo como esto:

test/test.ts:999:999 - error TS2344: Type '{ a: string; }' does not satisfy the constraint '{ a: \\"Expected: string, Actual: number\\"; }'.
  Types of property 'a' are incompatible.
    Type 'string' is not assignable to type '\\"Expected: string, Actual: number\\"'.

999 expectTypeOf({a: 1}).toEqualTypeOf<{a: string}>()

Observa que la restricción de tipo reportada es un mensaje legible que especifica tanto los tipos "esperado" como "real". En lugar de tomar la frase Types of property 'a' are incompatible // Type 'string' is not assignable to type "Expected: string, Actual: number" literalmente, concéntrate solo en el nombre de la propiedad ('a') y el mensaje: Expected: string, Actual: number. Esto te indicará el problema en la mayoría de los casos. Los tipos extremadamente complejos, por supuesto, requerirán más esfuerzo para depurar y pueden necesitar algo de experimentación. Por favor, abre una incidencia si los mensajes de error son realmente engañosos.

Los métodos toBe... (como toBeString, toBeNumber, toBeVoid, etc.) fallan al resolverse a un tipo que no se puede invocar cuando el tipo Actual bajo prueba no coincide. Por ejemplo, el fallo de una aserción como expectTypeOf(1).toBeString() se verá algo así:

test/test.ts:999:999 - error TS2349: This expression is not callable.
  Type 'ExpectString<number>' has no call signatures.

999 expectTypeOf(1).toBeString()
                    ~~~~~~~~~~

La parte This expression is not callable no es muy útil; el error significativo es la siguiente línea: Type 'ExpectString<number>' has no call signatures. Esto esencialmente significa que pasaste un número pero afirmaste que debería ser una cadena.

Si TypeScript añadiera soporte para tipos "throw", estos mensajes de error podrían mejorarse significativamente. Hasta entonces, requerirán un cierto esfuerzo de interpretación.

Objetos "esperados" concretos vs. argumentos de tipo ​

Los mensajes de error para una aserción como esta:

ts
expectTypeOf({ a: 1 }).toEqualTypeOf({ a: '' });

Serán menos útiles que para una aserción como esta:

ts
expectTypeOf({ a: 1 }).toEqualTypeOf<{ a: string }>();

Esto ocurre porque el compilador de TypeScript necesita inferir el argumento de tipo para el estilo .toEqualTypeOf({a: ''}), y esta biblioteca solo puede marcarlo como un fallo comparándolo con un tipo Mismatch genérico. Por lo tanto, siempre que sea posible, utiliza un argumento de tipo en lugar de un tipo concreto para .toEqualTypeOf y toMatchTypeOf. Si resulta mucho más conveniente comparar dos tipos concretos, puedes usar typeof:

ts
const one = valueFromFunctionOne({ some: { complex: inputs } });
const two = valueFromFunctionTwo({ some: { other: inputs } });

expectTypeOf(one).toEqualTypeOf<typeof two>();

Si te resulta difícil trabajar con la API expectTypeOf y descifrar errores, siempre puedes usar la API assertType más simple:

ts
const answer = 42;

assertType<number>(answer);
// @ts-expect-error answer no es un string
assertType<string>(answer);

TIP

Al usar la sintaxis @ts-expect-error, es posible que quieras asegurarte de no haber cometido un error tipográfico. Puedes hacerlo incluyendo tus archivos de tipo en la opción de configuración test.include, para que Vitest también ejecute estas pruebas y falle con un ReferenceError.

Esto pasará porque se espera un error. Sin embargo, la palabra "answer" tiene un error tipográfico, lo que resulta en un falso positivo:

ts
// @ts-expect-error answer no es un string
assertType<string>(answr);

Ejecutar Verificación de Tipos ​

Para habilitar la verificación de tipos, simplemente añade la bandera --typecheck a tu comando Vitest en package.json:

json
{
  "scripts": {
    "test": "vitest --typecheck"
  }
}

Ahora puedes ejecutar la verificación de tipos:

bash
npm run test
bash
yarn test
bash
pnpm run test
bash
bun test

Vitest utiliza tsc --noEmit o vue-tsc --noEmit, dependiendo de tu configuración, por lo que puedes eliminar estos scripts de tu flujo de trabajo.

Pager
AnteriorParalelismo
SiguienteInterfaz de usuario de Vitest

Publicado bajo la licencia MIT.

Copyright (c) 2021-Present Vitest Team

https://vitest.dev/guide/testing-types

Publicado bajo la licencia MIT.

Copyright (c) 2021-Present Vitest Team