Saltar al contenido principal

API

[Traducción Beta No Oficial]

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Vue Testing Library reexporta todo desde DOM Testing Library.

También expone estos métodos:

render(Component, options)​

La función render es la única forma de renderizar componentes en Vue Testing Library.

Toma hasta 2 parámetros y devuelve un objeto con algunos métodos de ayuda.

function render(Component, options) {
  return {
    ...DOMTestingLibraryQueries,
    container,
    baseElement,
    debug(element),
    unmount,
    html,
    emitted,
    rerender(props),
  }
}

Parámetros​

Componente​

El componente Vue válido que se va a probar.

Opciones​

Un objeto que contiene información adicional para pasar a @vue/test-utils mount.

Adicionalmente, también se pueden proporcionar las siguientes opciones:

store (Object | Store)​

La definición de objeto de un store Vuex. Si se proporciona un objeto store, Vue Testing Library importará y configurará un store Vuex. Si se pasa un store Vuex ya instanciado, se utilizará ese.

routes (Array | VueRouter)​

Un conjunto de rutas para Vue Router. Si se proporcionan routes, la librería importará y configurará Vue Router. Si se pasa una instancia de Vue Router ya creada, se utilizará esa.

props (Object)​

Se fusionará con propsData.

slots (Object)​

Se utiliza para proporcionar el contenido de los slots al renderizar el componente. Las claves son los nombres de los slots, y los valores pueden ser cadenas, fragmentos de plantilla o componentes, similar a cómo se definen los slots en Vue Test Utils.

Por ejemplo:

render(MyComponent, {
  slots: {
    default: 'Default',
    first: h('h1', {}, 'Named Slot'),
    second: Bar
  },
})
container (HTMLElement)​

Por defecto, Vue Testing Library creará un div y lo agregará al baseElement. Aquí es donde se renderizará tu componente. Si proporcionas tu propio contenedor HTMLElement mediante esta opción, no se agregará automáticamente al baseElement.

Por ejemplo: Si estás probando un elemento tablebody, no puede ser hijo de un div. En este caso, puedes especificar una table como container de renderizado.

const table = document.createElement('table')

const {container} = render(TableBody, {
  props,
  container: document.body.appendChild(table),
})
baseElement (HTMLElement)​

Si se especifica el container, entonces este por defecto será ese, de lo contrario, por defecto será document.body. baseElement se utiliza como el elemento base para las consultas y también para lo que se imprime cuando usas debug().

Resultado de render​

El método render devuelve un objeto con varias propiedades:

...queries​

La característica más importante de render es que las consultas de DOM Testing Library se devuelven automáticamente con su primer argumento vinculado al baseElement, que por defecto es document.body.

Consulta Queries para ver la lista completa.

const {getByLabelText, queryAllByTestId} = render(Component)

container​

El nodo DOM que contiene tu componente Vue renderizado. Por defecto es un div. Este es un nodo DOM regular, por lo que puedes llamar a container.querySelector etc. para inspeccionar los elementos hijos.

Consejo: Para obtener el elemento raíz de tu componente renderizado, usa container.firstChild.

🚨 ¡Si te encuentras usando container para consultar elementos renderizados, deberías reconsiderarlo! Las otras consultas están diseñadas para ser más resistentes a los cambios que se harán en el componente que estás probando. Evita usar container para consultar elementos.

baseElement​

El nodo DOM contenedor donde se renderiza tu componente Vue en el container. Si no especificas el baseElement en las opciones de render, por defecto será document.body.

Esto es útil cuando el componente que quieres probar renderiza algo fuera del div contenedor, por ejemplo, cuando quieres hacer una prueba de snapshot de tu componente de portal que renderiza su HTML directamente en el body.

Nota: las consultas devueltas por render buscan en baseElement, por lo que puedes usar consultas para probar tu componente de portal sin el baseElement.

debug(element)​

Este método es un atajo para console.log(prettyDOM(element)).

import {render} from '@testing-library/vue'

const HelloWorldComponent = {
  template: `<h1>Hello World</h1>`,
}

const {debug} = render(HelloWorldComponent)
debug()
// <div>
//   <h1>Hello World</h1>
// </div>

Es un envoltorio simple alrededor de prettyDOM, que también está expuesta y proviene de DOM Testing Library.

unmount()​

Un alias para @vue/test-utils unmount.

html()​

Un alias para @vue/test-utils html.

emitted()​

Un alias para @vue/test-utils emitted.

rerender(props)​

Un alias para @vue/test-utils setProps.

Devuelve una Promesa para que puedas hacer await rerender(...).

fireEvent​

Debido a que Vue aplica actualizaciones del DOM de forma asíncrona durante las re-renderizaciones, las herramientas fireEvent se reexportan como funciones async. Para garantizar que el DOM se actualice correctamente en respuesta a un evento durante una prueba, se recomienda siempre usar await con fireEvent.

await fireEvent.click(getByText('Click me'))

Adicionalmente, Vue Testing Library expone dos métodos útiles:

touch(elem)​

Provoca tanto los eventos focus() como blur().

await fireEvent.touch(getByLabelText('username'))

// Same as:
await fireEvent.focus(getByLabelText('username'))
await fireEvent.blur(getByLabelText('username'))

update(elem, value)​

Maneja correctamente los inputs controlados por v-model. Actualiza el valor interno del input/select/textarea mientras emite el evento nativo apropiado.

Consulta un ejemplo funcional de update en la prueba de ejemplo de v-model.

cleanup​

Desmonta los árboles de Vue que fueron montados con render.

Esto se llama automáticamente si tu framework de pruebas (como Mocha, Jest o Jasmine) inyecta una función global afterEach() en el entorno de pruebas. Si no es el caso, deberás llamar a cleanup() después de cada prueba.

No llamar a cleanup cuando has invocado render podría provocar fugas de memoria y pruebas no idempotentes (lo que puede generar errores difíciles de depurar en tus pruebas).