# Component Testing con Playwright y Cypress

**Categoría:** Testing y QA · **Nivel:** Intermedio · **Lectura:** 14 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/testing/component-testing-con-playwright-y-cypress/

## Respuesta rápida

El **component testing** (testing de componentes) prueba un **componente de interfaz de usuario aislado** —un botón, un formulario, una tarjeta— pero **renderizado de verdad en un navegador real**, no simulado. Es un **nivel intermedio** en la [pirámide de testing](../pruebas-unitarias-integracion-y-end-to-end/index.md), entre la prueba unitaria y la end-to-end, y esa posición explica su valor. Frente a una **unitaria**: la unitaria prueba lógica en un entorno simulado, sin navegador de verdad, y no ve cómo el componente *se renderiza* ni cómo responde a un clic real; el component testing sí, montando el componente en un navegador. Frente a una **end-to-end**: la e2e arranca toda la aplicación y navega por ella (lento y frágil); el component testing monta **solo ese componente**, aislado del resto de la app, así que es mucho más **rápido y estable**, y cuando falla sabés que el problema está *en el componente*. Es ideal para verificar que un componente **se ve y se comporta bien por sí solo**: que muestra lo correcto según sus datos de entrada, que reacciona a las interacciones, que maneja sus estados (cargando, error, vacío). Tanto [Playwright](../como-instalar-y-usar-playwright/index.md) como [Cypress](../como-instalar-y-usar-cypress/index.md) lo soportan con la misma idea: **montan el componente** en un navegador de pruebas y te dejan interactuar con él y hacer verificaciones. No reemplaza a los otros niveles: los **complementa**, cubriendo el hueco entre la lógica pura y el flujo completo.

## Qué es

Las interfaces modernas se construyen con **componentes**: piezas reutilizables de UI (un botón, un campo de búsqueda, una tarjeta de producto) que se combinan para armar las pantallas. El **component testing** prueba *cada una de esas piezas por separado*, pero **renderizada de verdad en un navegador**, verificando que se ve bien y se comporta como debe **por sí sola**, sin necesidad de levantar toda la aplicación.

> **Aislado, pero renderizado de verdad**
>
> La combinación clave es «aislado + renderizado real». **Aislado**: se monta solo ese componente, no la app entera, así que la prueba es rápida y, si falla, el culpable es el componente. **Renderizado de verdad**: se monta en un navegador real, no en una simulación, así que la prueba ve lo que el usuario vería y puede hacer clics y escribir como una persona. Ese matiz es lo que lo distingue de una prueba unitaria de UI, que corre en un entorno simulado.

## El nivel intermedio

Ubicarlo entre los otros dos niveles es lo que lo vuelve fácil de entender:

|  | Unitaria de UI | Component testing | End-to-end |
|---|---|---|---|
| Qué monta | Lógica, entorno simulado | Un componente, navegador real | La app completa |
| Realismo | Bajo (no renderiza de verdad) | Medio-alto | Máximo |
| Velocidad | Máxima | Alta | Baja |
| Si falla | Sabés la función | Sabés el componente | Puede ser cualquier cosa |

Qué conviene probar en este nivel: que el componente **muestre lo correcto** según los datos que recibe, que **reaccione** a las interacciones (clic, escritura), y que maneje bien sus **estados** (cargando, error, vacío, con datos). Lo que *no* va aquí: los flujos que atraviesan varias pantallas —eso es [end-to-end](../pruebas-unitarias-integracion-y-end-to-end/index.md)—.

## Playwright y Cypress

Tanto [Playwright](../como-instalar-y-usar-playwright/index.md) como [Cypress](../como-instalar-y-usar-cypress/index.md) —las mismas herramientas que se usan para [automatización e2e](../selenium-cypress-playwright/index.md)— ofrecen component testing, y la idea de fondo es la misma en ambas.

> **Atención**
>
> Ambas **montan el componente** en un navegador de pruebas —le pasás el componente y sus datos de entrada, y ellas lo renderizan aislado— y después te dejan **interactuar** con él (hacer clics, escribir) y **verificar** lo que muestra, con la misma API que ya usás para tus pruebas e2e. La ventaja de reutilizar la herramienta que ya conocés es enorme: la misma sintaxis, el mismo enfoque, para dos niveles distintos. Esta guía se centra en *qué es* el component testing y *cuándo* usarlo; para instalar y configurar cada herramienta en detalle, están las guías dedicadas de [Playwright](../como-instalar-y-usar-playwright/index.md) y [Cypress](../como-instalar-y-usar-cypress/index.md). Las diferencias concretas entre ellas se cubren en la [comparación de herramientas](../selenium-cypress-playwright/index.md).

## Errores frecuentes

- **Confundir component testing con unitaria.** La unitaria no renderiza de verdad; el component testing monta el componente en un navegador real.
- **Confundirlo con end-to-end.** El e2e levanta la app entera; el component testing monta solo el componente aislado.
- **Probar flujos entre pantallas aquí.** Eso es e2e; el component testing es para un componente por sí solo.
- **No probar los estados del componente.** Cargando, error y vacío son tan importantes como el estado con datos.
- **Duplicar en e2e lo ya cubierto por componente.** Encarece la suite; probar cada cosa en el nivel adecuado.
- **Montar demasiadas dependencias reales.** El valor es el aislamiento; si arrastra medio sistema, ya no es component testing.
- **Creer que reemplaza a los otros niveles.** Los complementa, cubriendo el hueco entre lógica y flujo.

## Preguntas frecuentes

**¿Qué es el component testing?**
El component testing, o testing de componentes, es un enfoque de prueba que verifica un componente de interfaz de usuario de forma aislada, pero renderizándolo de verdad en un navegador real, para comprobar que se ve correctamente y se comporta como debe por sí solo. Las interfaces modernas se construyen a partir de componentes, que son piezas reutilizables de la interfaz como un botón, un campo de formulario, una tarjeta o un menú, que luego se combinan para formar las pantallas completas. El component testing prueba cada una de esas piezas por separado, sin necesidad de levantar toda la aplicación, pero montándola en un navegador auténtico en lugar de en un entorno simulado. La combinación de estas dos características, aislamiento y renderizado real, es precisamente lo que define y da valor a este enfoque. El aislamiento significa que se monta solo el componente en cuestión, no la aplicación entera, lo que hace que las pruebas sean rápidas y que, cuando una falla, se sepa con certeza que el problema está en ese componente y no en otra parte del sistema. El renderizado real significa que el componente se muestra en un navegador de verdad, de modo que la prueba ve exactamente lo que vería el usuario y puede interactuar con el componente de forma auténtica, haciendo clics y escribiendo como lo haría una persona, algo que una prueba unitaria en un entorno simulado no puede reproducir con fidelidad. El component testing es especialmente útil para verificar que un componente muestra el contenido correcto según los datos que recibe, que reacciona adecuadamente a las interacciones, y que gestiona bien sus distintos estados, como cuando está cargando, cuando hay un error, cuando no hay datos o cuando muestra datos normales.

**¿En qué se diferencia de una prueba unitaria?**
El component testing y la prueba unitaria de interfaz se diferencian principalmente en el grado de realismo con que ejecutan el componente, y esa diferencia tiene consecuencias prácticas importantes. Una prueba unitaria de un componente de interfaz suele ejecutarse en un entorno simulado, es decir, una emulación por software del navegador que imita sus interfaces de programación pero que no es un navegador real; en ese entorno se puede comprobar la lógica del componente y ciertas cosas sobre su salida, de forma muy rápida, pero no se renderiza de verdad la interfaz tal como la vería un usuario, ni se ejecutan con total fidelidad los comportamientos que dependen del navegador auténtico, como el diseño real, algunos aspectos de los estilos, o la manera precisa en que el componente responde a interacciones genuinas. El component testing, en cambio, monta el componente en un navegador real, de modo que se renderiza de verdad y se puede interactuar con él como lo haría una persona, con clics y escritura auténticos, viendo el resultado tal como se vería en la práctica. Esto aporta un realismo del que carece la unitaria, permitiendo detectar problemas que solo se manifiestan cuando el componente se dibuja y se maneja en un navegador de verdad. La contrapartida es que el component testing es algo más lento y pesado que una unitaria pura, porque implica un navegador. Por eso ambos enfoques tienen su lugar: la unitaria es ideal para la lógica pura y las comprobaciones que no requieren renderizado real, aprovechando su gran velocidad, mientras que el component testing es ideal cuando importa verificar el comportamiento y el aspecto reales del componente en un navegador, sin llegar al costo de una prueba de extremo a extremo de toda la aplicación.

**¿En qué se diferencia de una prueba end-to-end?**
El component testing y la prueba end-to-end se diferencian en cuánto del sistema ponen en marcha, y esa diferencia determina su velocidad, su estabilidad y la precisión con que localizan los fallos. Una prueba end-to-end arranca la aplicación completa y la recorre como lo haría un usuario real, navegando entre pantallas, atravesando todas las capas del sistema desde la interfaz hasta la base de datos, para verificar un flujo entero de principio a fin. Esto la hace muy realista y valiosa para confirmar que un camino crítico funciona en su totalidad, pero también la vuelve lenta, porque ejecuta todo el sistema, y frágil, porque al depender de tantas partes puede fallar por motivos ajenos al componente que interesa, como demoras, problemas de entorno o cambios en otras pantallas; además, cuando falla, el problema puede estar en cualquier punto del largo recorrido, lo que dificulta el diagnóstico. El component testing, en cambio, monta un único componente de forma aislada, sin el resto de la aplicación, aunque renderizado de verdad en un navegador. Esto lo hace mucho más rápido, porque no tiene que levantar todo el sistema; mucho más estable, porque hay menos piezas que puedan fallar por causas externas; y mucho más preciso al diagnosticar, porque si una prueba de componente falla, se sabe que el problema está en ese componente concreto. La contrapartida es que el component testing no verifica que las piezas encajen entre sí ni que los flujos completos funcionen, ya que prueba componentes por separado. Por eso ambos niveles son complementarios y no rivales: el component testing cubre de forma eficiente el comportamiento y el aspecto de cada componente aislado, mientras que unas pocas pruebas end-to-end, reservadas para los flujos críticos, confirman que todo el sistema funciona junto. Ubicar cada verificación en el nivel adecuado evita duplicar esfuerzo y mantiene la suite rápida y confiable.

**¿Qué conviene probar con component testing?**
El component testing es el nivel adecuado para verificar el comportamiento y el aspecto de un componente de interfaz por sí solo, y hay varias cosas concretas que conviene probar en él. La primera es que el componente muestre el contenido correcto en función de los datos de entrada que recibe: como los componentes suelen recibir información desde fuera y renderizarla, se comprueba que ante distintos conjuntos de datos de entrada el componente presenta lo que corresponde, por ejemplo que una tarjeta de producto muestra el nombre, el precio y la imagen adecuados según los datos que se le pasan. La segunda es que el componente reaccione correctamente a las interacciones del usuario: se simulan acciones reales como hacer clic en un botón, escribir en un campo, marcar una casilla o desplegar un menú, y se verifica que el componente responde como debe, por ejemplo emitiendo el evento esperado, cambiando su apariencia o actualizando su contenido. La tercera, y a menudo la más olvidada, es que el componente maneje bien todos sus estados posibles: además del estado normal con datos, conviene probar el estado de carga mientras se esperan datos, el estado de error cuando algo falla, y el estado vacío cuando no hay datos que mostrar, ya que estos estados son fuente habitual de defectos y descuidos en la interfaz. En cambio, lo que no conviene probar en este nivel son los flujos que atraviesan varias pantallas o que dependen de la integración de muchos componentes y capas del sistema, porque eso corresponde a las pruebas de extremo a extremo. La regla es que el component testing se ocupa de que cada pieza de interfaz funcione y luzca bien de forma aislada, dejando la verificación de que las piezas encajan y los flujos completos funcionan para los niveles superiores. Enfocar el component testing en el comportamiento aislado del componente aprovecha al máximo su velocidad y su capacidad de localizar fallos con precisión.

**¿Cómo lo abordan Playwright y Cypress?**
Tanto Playwright como Cypress, que son dos de las herramientas más populares para la automatización de pruebas de interfaz, ofrecen capacidades de component testing, y aunque cada una tiene sus particularidades, la idea de fondo es la misma en ambas. El mecanismo básico consiste en que la herramienta monta el componente que se quiere probar en un navegador de pruebas: se le indica cuál es el componente y qué datos de entrada debe recibir, y la herramienta lo renderiza de forma aislada, sin el resto de la aplicación, en un navegador real. A partir de ahí, la herramienta permite interactuar con el componente montado, simulando acciones de usuario como clics y escritura, y hacer verificaciones sobre lo que el componente muestra o sobre cómo reacciona, comprobando que su comportamiento y su aspecto son los esperados. Una gran ventaja de que estas herramientas ofrezcan component testing es que se utiliza prácticamente la misma sintaxis y el mismo enfoque que ya se emplean para las pruebas de extremo a extremo con esas mismas herramientas, de modo que quien ya conoce la herramienta para un nivel puede aplicarla al otro con muy poca curva de aprendizaje adicional, reutilizando su conocimiento de la interfaz de programación y de las formas de seleccionar elementos, interactuar y verificar. Esta guía se centra deliberadamente en explicar qué es el component testing y cuándo conviene usarlo, mientras que los detalles concretos de instalación, configuración y uso de cada herramienta están cubiertos en las guías dedicadas a instalar y usar Playwright y a instalar y usar Cypress, y las diferencias generales entre ambas herramientas se tratan en la guía comparativa correspondiente. De este modo, para adoptar el component testing basta con elegir la herramienta que ya se use o se prefiera, apoyarse en su guía específica para la puesta en marcha, y aplicar los principios de qué probar en este nivel que se explican aquí.

**¿El component testing reemplaza a los otros niveles?**
No, el component testing no reemplaza a los otros niveles de prueba, sino que los complementa, ocupando un hueco específico dentro de una estrategia de testing equilibrada. Cada nivel tiene un propósito distinto y aporta un tipo de confianza diferente, por lo que lo adecuado es combinarlos y no sustituir unos por otros. Las pruebas unitarias siguen siendo la base más numerosa y económica para verificar la lógica pura, como cálculos, validaciones y reglas, de forma rapidísima y precisa, y el component testing no las sustituye en ese terreno. Las pruebas de extremo a extremo siguen siendo necesarias, en pequeña cantidad, para confirmar que los flujos críticos completos del producto funcionan de verdad a través de todo el sistema integrado, algo que el component testing, al probar componentes aislados, no puede verificar. Lo que aporta el component testing es cubrir eficientemente el espacio intermedio: verificar que cada componente de interfaz se ve y se comporta correctamente por sí solo, en un navegador real, con mucha más velocidad y estabilidad que una prueba de extremo a extremo y con más realismo que una prueba unitaria en entorno simulado. Al hacerlo, permite reducir la cantidad de pruebas de extremo a extremo necesarias, porque muchas comprobaciones sobre el comportamiento de la interfaz que antes solo podían hacerse levantando toda la aplicación ahora se pueden hacer a nivel de componente, de forma más barata y fiable, reservando las pruebas de extremo a extremo para lo que realmente requiere el sistema completo. En términos de la pirámide de testing, el component testing enriquece la franja intermedia y ayuda a mantener una proporción sana, con abundancia de pruebas rápidas y pocas pruebas lentas. En definitiva, la mejor práctica es usar los niveles de forma coordinada, probando cada cosa en el nivel más bajo y adecuado que pueda darle confianza, y el component testing es una herramienta valiosa dentro de ese conjunto, no un sustituto de los demás.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección Desarrollo web](https://underc0de.org/foro/desarrollo-web/). Testing de interfaces.
2. **Underc0de, foro.** [Sección Programación](https://underc0de.org/foro/programacion/). Componentes y frameworks.

### Documentación oficial

1. **Cypress.** [Component Testing](https://docs.cypress.io/guides/component-testing/overview). Documentación oficial del enfoque en Cypress.
2. **Playwright.** [Components](https://playwright.dev/docs/test-components). Component testing en Playwright.
3. **Testing Library.** [Guiding Principles](https://testing-library.com/docs/). Probar componentes como los usa el usuario.
4. **Storybook.** [Testing de componentes](https://storybook.js.org/docs/writing-tests). Enfoque complementario.

## Guías relacionadas

- [Niveles de prueba](../pruebas-unitarias-integracion-y-end-to-end/index.md)
- [Selenium, Cypress, Playwright](../selenium-cypress-playwright/index.md)
- [Instalar y usar Playwright](../como-instalar-y-usar-playwright/index.md)
- [Instalar y usar Cypress](../como-instalar-y-usar-cypress/index.md)
- [Índice de Testing y QA](../index.md)