Cucumber bien usado… ¿es posible?

Cucumber es una de esas herramientas que generan amor, odio (más odio creería)… y muchos archivos .feature que nadie vuelve a leer.

¿Te pasó? Porque a mi me pasó bocha.

Muchos equipos adoptan Cucumber con la idea de fomentar la colaboración entre testers, devs y product owners porque leyeron algún post sobre los famosos "3 amigos". Pero la realidad es que en muchos casos:

• Los pasos se escriben como si fueran código disfrazado de texto

• Los features no los lee nadie fuera del equipo de QA

• Hay duplicación de lógica y cero mantenibilidad

Entonces… ¿Cucumber bien usado es posible?

La respuesta es: sí, pero no como lo estás usando ahora.

¿Cuál es el verdadero valor de Cucumber?

Cucumber se basa en el lenguaje Gherkin. La idea es escribir escenarios que cualquiera pueda leer y entender. Su objetivo principal no es automatizar tests, sino comunicar claramente el comportamiento esperado de una funcionalidad.

Cuando se usa bien, Cucumber permite:

• Escribir criterios de aceptación claros

• Validar el comportamiento del sistema en lenguaje natural

• Facilitar el entendimiento entre personas técnicas y no técnicas

El problema es que muchas veces se convierte en una capa innecesaria sobre una automatización que podría hacerse más simple con JUnit o TestNG.

Cucumber mal usado: los 3 errores más comunes

1. Pasos genéricos para todo

Given I click on "Login"
Then I see "Dashboard"

1. Eso no dice nada sobre el negocio. Podría ser cualquier aplicación.

2. Automatización sin colaboración

   Los testers escriben los .feature, los devs ni los leen, el PO ni sabe que existen. Se pierde el propósito de comunicación.

3. Escenarios con lógica técnica

   Escenarios escritos en lenguaje natural pero con estructura mental de código:

Given I set header "X-Token" with value "abc123"

¿Quién fuera del equipo técnico puede entender eso?

¿Cómo usar Cucumber de forma efectiva?

👉 1. Escribí los escenarios desde el negocio

Usá lenguaje del dominio. Si el usuario inicia sesión para ver su saldo, decilo así.

No digas “hace clic en el botón verde”, decí “accede a su resumen de cuenta”.

👉 2. Mantené los pasos reutilizables, pero legibles

Evitá la sobreabstracción. El escenario tiene que leerse como una conversación, no como una receta con mil pasos técnicos.

👉 3. Revisá los features con el equipo

Si nadie más lee tus archivos .feature, estás perdiendo el punto central de usar Cucumber. Hacelo parte de tus refinamientos o dailies.

¿Querés aprender a usar Cucumber como corresponde?

Si estás cansado de usar Cucumber solo porque “el cliente lo pidió” o porque “estaba en el framework”, armé un curso donde te enseño desde cero a usar Selenium con Cucumber y Java, pero con enfoque profesional.

🎓 Curso de Selenium + Cucumber + Java – Free Range Testers

Aprendés:

• Cómo escribir escenarios legibles y mantenibles

• Cómo estructurar los Steps y el Page Object Model

• Cómo trabajar con datos dinámicos en Cucumber

• Cómo evitar duplicación y escribir tests escalables

Cucumber no es la solución mágica. Pero bien usado… suma.

Si buscás que tu suite de tests sea más que una repetición en lenguaje natural, y querés que realmente ayude a comunicar comportamiento esperado: Cucumber puede ser una gran herramienta.

Pero como cualquier herramienta, no se trata de usarla, sino de usarla bien.

💬 ¿Estás usando Cucumber en tu proyecto? ¿Tenés ejemplos de buen (o mal) uso que quieras compartir? Te leo en los comentarios.