Validar si una prueba pasa o falla depende de un elemento clave: las aserciones en Cypress. Aquí aprendes las tres formas de escribirlas (BDD, TDD y Chai jQuery), cuándo usar cada una y cómo combinarlas en proyectos reales de automatización con QA.

Una prueba sin aserción es como un examen sin respuestas. Si no validas el resultado, no estás probando nada. Por eso, cada test que escribas debería incluir al menos una validación que confirme tu criterio de aceptación.

¿Qué son las aserciones en Cypress y por qué importan?

Las aserciones son las instrucciones que le dicen a Cypress qué resultado esperas. Si el resultado real coincide, la prueba pasa y se muestra en verde. Si no, falla y aparece en rojo con el detalle del error.

¿Qué es una aserción en testing? Es una validación que compara un resultado real contra uno esperado. Si coinciden, la prueba pasa; si no, falla y muestra el motivo.

Cypress ofrece tres formas de escribirlas y todas son válidas. La elección depende del estilo que tu equipo haya acordado.

¿Cómo se usa el comando should para aserciones BDD?

El primer estilo es BDD (Behavior Driven Development) y se basa en la palabra should, que en inglés significa "debe de". La sintaxis se lee casi como una frase natural: el elemento debe ser visible, debe incluir cierto valor o debe tener un atributo.

Un ejemplo clásico es validar la URL después de una navegación:

js cy.url().should('include', 'demoqa.com')

Esto sirve para confirmar que, tras hacer clic en un botón o navegar a una sección, terminaste en la página correcta. Cypress espera unos segundos a que cargue y luego compara.

¿Cómo encadenar varias aserciones con and?

Cuando quieres validar más de una cosa sobre el mismo elemento, puedes encadenar should o usar and para mejorar la legibilidad. Por ejemplo, sobre un input de first name:

js cy.get('#firstName') .should('be.visible') .and('have.attr', 'placeholder', 'First Name')

Este bloque verifica que el input esté visible y que su atributo placeholder tenga el valor exacto. Si el elemento existe en el DOM pero está oculto por CSS, be.visible lo detecta y la prueba falla.

¿Cómo se hacen aserciones con expect y Chai jQuery?

La segunda forma usa expect dentro de un bloque then. Aquí ya no trabajas con el comando encadenado de Cypress, sino con el elemento jQuery directamente. Esto es útil cuando necesitas validar variables, valores externos o cosas que no vienen del flujo normal de Cypress.

js cy.get('#firstName').then((element) => { expect(element).to.be.visible expect(element).to.have.attr('placeholder', 'First Name') })

¿Cuándo uso expect en lugar de should? Usa expect cuando trabajas dentro de un then con elementos jQuery o variables externas a Cypress. Usa should para validaciones directas sobre comandos encadenados.

La sintaxis cambia un poco, pero la lógica es la misma. Ambas formas pueden convivir en la misma suite sin problema.

¿Qué diferencia hay entre TDD, BDD y assert en Cypress?

La tercera forma es TDD (Test Driven Development) y usa la palabra assert. Su estilo es más directo y se enfoca en afirmar igualdades o comparaciones específicas:

js cy.get('#firstName').then((element) => { assert.equal(element.attr('placeholder'), 'First Name') })

Las tres opciones cumplen la misma función pero con enfoques distintos:

• BDD con should: descriptivo, lee como comportamiento esperado.
• Chai con expect: flexible, ideal para validar fuera del flujo Cypress.
• TDD con assert: directo, orientado a comparaciones explícitas.

Ninguna es mejor que otra. Cypress se apoya en Chai, una librería de Node muy popular para aserciones, y eso explica por qué tienes acceso a comandos como equal, greater than, not equal o have.attr. Si buscas en Google Cypress assertions, encontrarás la lista completa de cadenas disponibles.

¿Cómo elegir el estilo de aserción para tu proyecto?

La decisión depende del equipo. Lo importante es mantener consistencia: si todos en el proyecto usan should, evita mezclar assert sin razón. La unicidad en el código facilita el mantenimiento y la lectura.

Algunas señales para decidir:

• Si tu equipo viene de un enfoque BDD, should con and se siente natural.
• Si necesitas validar valores externos a Cypress, expect te da más control.
• Si prefieres comparaciones explícitas tipo equal, assert es claro y conciso.

Cualquiera que elijas, recuerda que una prueba sin aserción no prueba nada. Y cuando una falla, Cypress te muestra exactamente qué esperaba y qué encontró, para que puedas depurar rápido.

¿Cuál de los tres estilos usas en tu día a día? Cuéntame en los comentarios qué convenciones siguen en tu equipo de QA.