Talently
Talently
Cypress

Cypress

El framework de testing end-to-end para aplicaciones web modernas

Cypress es un framework de testing end-to-end diseñado específicamente para aplicaciones web modernas. A diferencia de soluciones basadas en Selenium, Cypress se ejecuta directamente en el navegador con acceso completo a la aplicación, ofreciendo una experiencia de desarrollo fluida con recarga en tiempo real, depuración visual y una API intuitiva. Soporta tests E2E, tests de integración y tests de componentes.

JavaScriptTypeScriptE2ETesting

Demanda del mercado

Cypress es el framework de testing E2E más adoptado en el ecosistema JavaScript, con alta demanda en equipos que trabajan con React, Vue o Angular y quieren automatizar tests de usuario sin la complejidad de Selenium.

Framework E2E más popular en JavaScriptAlta demanda en equipos frontend modernosEstándar en CI/CD de aplicaciones web

Requisitos técnicos

Intermediate

Requiere dominio de JavaScript o TypeScript y comprensión de los conceptos de testing como assertions, fixtures y mocking. Familiaridad con la aplicación bajo test y con herramientas de CI/CD es importante para integrar Cypress en pipelines de entrega continua.

Casos de uso

Proyectos Reales

Cypress se utiliza para desarrollar:

  • Tests E2E de flujos críticos de usuario como registro y checkout
  • Tests de integración de componentes React, Vue o Angular
  • Tests de regresión automatizados en pipelines CI/CD
  • Tests de APIs con cy.request para validar endpoints

Tipos de Empresa

Cypress es adoptado por:

  • Startups con productos web que necesitan cobertura de regresión
  • Equipos con desarrollo ágil que automatizan tests de aceptación
  • Empresas con CI/CD donde los tests E2E son gate de despliegue
  • Agencias con proyectos web donde el cliente requiere cobertura de tests

Escenarios de Producción

Cypress es ampliamente utilizado en entornos productivos como:

  • Pipelines CI/CD con Cypress en GitHub Actions o CircleCI
  • Tests de smoke después de cada despliegue en producción
  • Tests de regresión visual con capturas de pantalla
  • Grabación de tests fallidos con video para debugging

Escalabilidad

Cypress ofrece múltiples mecanismos para escalar aplicaciones:

  • Cypress Cloud para paralelización de tests en múltiples máquinas
  • Agrupación de tests por tags para ejecución selectiva
  • Fixtures y custom commands para reducir duplicación
  • Integración con Slack y Jira para notificación de fallos

Ventajas y Desventajas

Ventajas

Ejecución en el mismo proceso del navegador con acceso directo al DOM y a las APIs de la app.

Time-travel debugging con snapshots de cada comando ejecutado.

Recarga automática de tests y experiencia de desarrollo interactiva.

Desventajas

Soporte limitado para múltiples tabs y dominios cruzados en el mismo test.

No soporta múltiples navegadores simultáneamente en un mismo test.

Los tests E2E son inherentemente más lentos y frágiles que los unitarios.

Comparación

Ventajas de Playwright

  • Soporte nativo para múltiples tabs y dominios cruzados
  • Tests en paralelo por defecto con mejor rendimiento
  • Mejor soporte para aplicaciones móviles con dispositivos emulados

Consideraciones

Playwright es la alternativa moderna de Microsoft con mejores capacidades para escenarios complejos multi-tab y multi-dominio. Cypress tiene mejor experiencia de desarrollo interactiva y mayor adopción en el ecosistema JavaScript frontend.

Preguntas básicas

Cypress se ejecuta directamente en el navegador con acceso al DOM y a las APIs de la aplicación, ofreciendo mejor fiabilidad sin problemas de sincronización de Selenium. La experiencia de desarrollo es significativamente mejor con recarga automática, time-travel debugging y una API fluida sin boilerplate de setup.
Cypress es preferible cuando el equipo ya tiene experiencia con él, el proyecto es una SPA sin requisitos de múltiples tabs o dominios cruzados y se valora la experiencia interactiva de desarrollo. Playwright es preferible cuando se necesitan tests en múltiples tabs, mejor paralelización nativa o capacidades móviles avanzadas.
Cypress cubre la cima de la pirámide con tests E2E que verifican flujos completos de usuario y la capa intermedia con tests de integración de componentes. Se complementa con Jest o Vitest para tests unitarios en la base de la pirámide. Los tests E2E son los más lentos y costosos de mantener por lo que deben cubrir los flujos críticos y no reemplazar los unitarios.
Son comandos personalizados que extienden la API de Cypress con acciones reutilizables específicas del proyecto como cy.login(), cy.createUser() o cy.fillForm(). Se definen en commands.js y se usan en todos los tests, reduciendo la duplicación de código y haciendo los tests más legibles y mantenibles.
Cypress usa un sistema de comandos encolados que se ejecutan secuencialmente con retry automático hasta que el elemento existe y cumple la condición, o hasta que expira el timeout. No se necesitan await ni callbacks explícitos ya que Cypress gestiona la asincronía internamente, haciendo el código más legible.
Son archivos de datos estáticos en formato JSON o JavaScript que proveen datos de prueba reutilizables para los tests. Se cargan con cy.fixture() y permiten centralizar los datos de test separándolos del código del test, facilitando el mantenimiento cuando los datos cambian y permitiendo reutilizarlos entre múltiples tests.
Ejecutando cypress run en modo headless en el pipeline, configurando variables de entorno para la URL de la aplicación en cada entorno, usando Cypress Cloud para paralelización y grabación de resultados, configurando reintentos para tests que fallan por inestabilidad de red y estableciendo el resultado de Cypress como gate para el despliegue.
Para tests E2E de flujos de usuario completos en SPAs con React, Vue o Angular, tests de integración de componentes en el navegador real, tests de APIs con cy.request que verifican el contrato del backend, y tests de regresión visual con capturas de pantalla que detectan cambios no intencionados en la UI.

Preguntas técnicas

Creando clases o módulos que encapsulan los selectores y las acciones de cada página en métodos con nombres descriptivos. Los tests usan los métodos del Page Object en lugar de acceder directamente al DOM, haciendo los tests más legibles y centralizando el impacto de los cambios de la UI en los Page Objects en lugar de en múltiples tests.
Usando cy.intercept() para interceptar requests HTTP por URL o método, pudiendo devolver respuestas mockeadas con fixture, modificar la respuesta real o añadir delays para simular latencia. Permite testear estados de error, respuestas lentas o datos específicos sin depender del backend real, haciendo los tests más rápidos y predecibles.
Programando el estado de autenticación directamente con cy.request() para obtener el token y establecerlo en localStorage o cookies con cy.setCookie(), o usando un comando personalizado cy.login() que llama a la API de login directamente sin pasar por la UI. Esto hace los tests más rápidos y menos frágiles que navegar por el formulario de login en cada test.
Configurando Cypress con el devServer de Vite, Webpack o el bundler del proyecto, montando componentes individuales con cy.mount() y probando su comportamiento en aislamiento en un navegador real. Es útil para componentes con comportamiento complejo que depende del entorno real del navegador como drag and drop o APIs de Canvas.
Usando .as('nombreAlias') para crear un alias a un elemento, una intercepción o un fixture, y accediéndolo posteriormente con cy.get('@nombreAlias'). Los aliases persisten durante el test y permiten referenciar elementos o datos creados en pasos anteriores sin tener que volver a buscarlos o redefinirlos.
Usando el plugin cypress-axe que integra axe-core con Cypress. Se instala el plugin, se inyecta axe con cy.injectAxe() después de cargar la página y se ejecuta el análisis con cy.checkA11y() que falla el test si encuentra violaciones de accesibilidad según las reglas configuradas de WCAG.
Creando los datos necesarios para cada test en beforeEach con cy.request() llamando a APIs de setup del backend, o usando comandos de base de datos para resetear el estado. Se evita compartir estado entre tests ya que el orden de ejecución puede variar y los tests deben ser independientes y ejecutables en cualquier orden.
Revisando los videos y screenshots grabados por Cypress en CI, añadiendo cy.log() para trazabilidad en el test, verificando si hay condiciones de carrera con peticiones de red usando cy.intercept() para esperar explícitamente las respuestas, comprobando si hay diferencias de timing entre entornos con waitFor y revisando si los selectores son suficientemente específicos.

Preguntas avanzadas

Organizando los tests por feature o dominio de negocio en carpetas, usando Page Objects o App Actions para abstraer las interacciones con la UI, definiendo custom commands para acciones comunes como autenticación y creación de datos, usando tags para clasificar tests por criticidad y velocidad, y separando los smoke tests de los tests de regresión completos.
Usando plugins como cypress-image-snapshot o integrando con Applitools o Percy que comparan capturas de pantalla con baselines aprobadas. Se configuran los tests visuales para capturar componentes o páginas completas después de acciones específicas, se revisan las diferencias en el dashboard del servicio y se aprueban los cambios intencionales actualizando el baseline.
Desactivando las animaciones CSS en el entorno de test con un comando global que añade una clase CSS que establece transition-duration y animation-duration a cero, usando cy.wait() solo cuando sea imprescindible y preferiendo cy.intercept().as().wait() para esperar operaciones de red específicas, y verificando condiciones de estado con assertions en lugar de tiempos fijos.
Usando Cypress Cloud con el flag --parallel que distribuye los specs entre los workers disponibles según el historial de duración de cada spec. Se configura el número de máquinas paralelas en el pipeline CI y Cypress Cloud balancea automáticamente la carga. Alternativamente se dividen manualmente los specs entre jobs paralelos en el pipeline.
Mapeando primero los flujos críticos de negocio como registro, autenticación, checkout o acciones core del producto, priorizando por impacto y riesgo, comenzando por los smoke tests que cubren el happy path de cada flujo, añadiendo gradually los edge cases y flujos de error más frecuentes y midiendo la cobertura de funcionalidades críticas en lugar de cobertura de código.
Ejecutando los smoke tests en cada PR como check obligatorio, los tests de regresión completos en merges a main, haciendo los tests parte del Definition of Done para nuevas features, integrando los resultados en el dashboard del equipo con notificaciones en Slack para fallos, y rotando la responsabilidad de mantener los tests entre los developers para que no sea responsabilidad de QA únicamente.

Errores comunes en entrevistas

Elegir Cypress sin poder articular sus ventajas y limitaciones frente a Playwright refleja falta de criterio. Se espera conocer cuándo las capacidades multi-tab y la mejor paralelización de Playwright justifican su mayor complejidad frente a la mejor experiencia interactiva de Cypress.
Seleccionar elementos con cy.get('.btn-primary') o rutas de DOM frágiles genera tests que se rompen con cualquier cambio de estilos o estructura. Se espera usar atributos data-cy o data-testid específicos para testing, o selectores basados en texto accesible como labels y roles.
Tests que dependen del estado real del backend son lentos, no deterministas y se rompen por razones ajenas al código bajo test. No conocer cy.intercept para mockear respuestas refleja inexperiencia escribiendo tests E2E mantenibles.
Navegar por el flujo completo de login en cada test hace la suite lenta y frágil. No conocer cómo establecer el estado de autenticación programáticamente refleja inexperiencia optimizando suites de tests Cypress en proyectos reales.
Tener tests Cypress que solo se ejecutan manualmente en local sin integración en CI refleja no haber implementado Cypress en un proyecto real en producción. Se espera conocer cómo configurar el modo headless y los artefactos de video y screenshots en CI.
Desconocer que Cypress puede hacer tanto tests E2E completos como tests de componentes individuales refleja no seguir la evolución del framework. Se espera conocer cuándo usar cada modalidad según el nivel de la pirámide de testing que se quiere cubrir.