En desarrollo de Software, la automatización de las pruebas es vital para garantizar la calidad del producto. Prácticas ágiles como Entrega Contínua la tienen con un pilar fundamental para obtener los beneficios esperados. Y es que al desarrollar pruebas junto con el código de la implementación, estamos promoviendo a que los errores sean identificados en etapas tempranas en el ciclo de vida del desarrollo de Software, reduciendo así los costos que representaría identificar estos mismos errores ya cuando el Software esté operativo.

Para las organizaciones que compiten en un mercado muy exigente, mantener sus productos de Software actualizados con las necesidades de sus clientes internos y externos puede ser la diferencia entre seguir operando o desaparecer. El contar con pruebas automatizadas hará que estos cambios puedan surgir en menor tiempo.

¿Por dónde comenzar?

Ahora que sabemos que tener pruebas automatizadas es importante, suele ocurrir que, como no estamos habituados a escribirlas, no sabemos por donde comenzar. Una alternativa es aplicar TDD, lo cual nos ayuda no solamente a tener un conjunto aceptable de pruebas sino que también evita que caigamos en la sobre-ingeniería, manteniendo un diseño simple en nuestro código.

Las pruebas unitarias que se obtienen de aplicar TDD sirven como documentación para que otros desarrolladores se familiaricen con la funcionalidad esperada. Además, nos sirven como un red de protección ya que podremos comprobar al ejecutar la mismas que no hayamos afectado negativamente algo que la aplicación está esperando.

Sin embargo, estas pruebas no son de mucha ayuda cuando deseamos la participación de otros actores que no tengan el nivel un técnico de los desarrolladores. Aquí es donde herramientas como Cucumber pueden ser de mucha ayuda ya que permiten la definición de pruebas de aceptación en un lenguaje que el negocio conoce. Mediante ejemplos reales se puede identificar los escenarios prioritarios que el Software debe implementar.

Se puede definir a Cucumber como una herramienta BDD, ya que promueve a que primero escribamos una prueba de aceptación y luego proceder a la implementación para pasar la misma.

¿Y qué es BDD?

Behavior-driven development (BDD) es un proceso de desarrollo de Software que emerge de TDD y que ayuda a que el equipo de desarrollo y los conocedores del negocio colaboren de mejor manera durante la creación del producto de Software.

Manteniendo un enfoque top-down, se inicia con la definición de un caso en particular del negocio, escrito en el lenguaje del día a día de los involucrados. Esta simple definición serviría nada más como documentación de los que esperamos del sistema, pero este proceso de desarrollo busca que este requerimiento definido como una prueba de aceptación sea automatizado para validar su cumplimiento en cualquier momento.

Al  igual que TDD todo comienza con una definición que esperamos que falle para luego proceder a implementarla. Aquí es donde se pone interesante el asunto ya que para esa implementación podríamos hacer uso de TDD en cada uno de los elementos que se vayan a desarrollar en los niveles inferiores.

Si deseas ver cómo todo esto puede ser utilizado desde una aplicación en Java puedes visitar la siguiente entrada Cucumber + Spring boot 2 + Junit 5

Resumen y conclusiones

• El uso de un lenguaje natural de negocio ayuda enormemente a que los actores principales se involucran en la concepción del producto de Software y en la validación posterior del mismo.
• BDD también es de mucha ayuda cuando no sepamos por dónde iniciar nuestras pruebas ya que este enfoque pone en evidencia lo que resulta de prioridad para el negocio.

Referencias

• https://en.wikipedia.org/wiki/Continuous_delivery
  
• https://en.wikipedia.org/wiki/Test-driven_development
  
• https://en.wikipedia.org/wiki/Unit_testing
  
• https://cucumber.io/
  
• https://en.wikipedia.org/wiki/Acceptance_testing
  
• https://en.wikipedia.org/wiki/Unit_testing
  
• https://en.wikipedia.org/wiki/Top-down_and_bottom-up_design