Saltar al contenido principal

Introducción

[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 →

La familia de paquetes @testing-library te ayuda a probar componentes de UI de manera centrada en el usuario.

Cuanto más se asemejen tus pruebas a cómo se usa tu software, más confianza podrán darte.

El problema

Quieres escribir pruebas mantenibles que te den alta confianza en que tus componentes funcionan para tus usuarios. Como parte de este objetivo, debes evitar que tus pruebas incluyan detalles de implementación, así las refactorizaciones de tus componentes (cambios en implementación sin alterar funcionalidad) no romperán tus pruebas ni ralentizarán a tu equipo.

La solución

La biblioteca principal, DOM Testing Library, es una solución ligera para probar páginas web mediante consultas e interacciones con nodos DOM (ya sea simulados con JSDOM/Jest o en navegador real). Sus utilidades principales permiten consultar el DOM para encontrar nodos de forma similar a cómo los usuarios localizan elementos en la página. Así, la biblioteca garantiza que tus pruebas te den confianza en que tu aplicación funcionará cuando usuarios reales la utilicen.

La biblioteca principal se ha adaptado para ofrecer APIs ergonómicas en varios frameworks como React, Angular y Vue. También existe un plugin para usar consultas de testing-library en pruebas end-to-end con Cypress, y una implementación para React Native.

Lo que esta biblioteca no es

  1. Un ejecutor de pruebas (test runner) ni framework de testing

  2. Específico de un framework de testing

DOM Testing Library funciona con cualquier entorno que proporcione APIs DOM, como Jest, Mocha + JSDOM o navegadores reales.

Lo que debes evitar con Testing Library

Testing Library te anima a evitar probar detalles de implementación como los internos de un componente que estás probando (aunque sigue siendo posible). Los Principios Rectores de esta biblioteca enfatizan un enfoque en pruebas que se asemejen estrechamente a cómo los usuarios interactúan con tus páginas web.

Debes evitar estos detalles de implementación:

  1. Estado interno de un componente

  2. Métodos internos de un componente

  3. Métodos del ciclo de vida de un componente

  4. Componentes hijos