BDD vs TDD. Diferencias y aplicaciones

Para poder comenzar a diferenciar y ver las posibles aplicaciones de BDD y TDD, primero debemos tener claros ciertos conceptos. BDD vs TDD: ¿en qué se diferencian y cuál es la mejor aplicación para cada una de estas estrategias?

Aunque ambas son estrategias de desarrollo, existen muchas diferencias entre ellas. La principal, como sus nombres indican, es quién o qué dirige el desarrollo. En el caso de TDD (Test Driven Development) o desarrollo dirigido por pruebas, son justamente las pruebas las que van a marcar el camino a seguir. Es decir, primero escribimos las pruebas (en este caso, de tipo unitarias) y luego desarrollamos nuestra aplicación de tal manera que las pruebas escritas con anterioridad pasen siempre correctamente.  

Por la otra parte, se encuentra el caso de BDD (Behavior Driven Development) o desarrollo dirigido por el comportamiento. Aunque en este caso el desarrollo también se dirige por las pruebas, son totalmente distintas, ya que lo hace centrándose en una perspectiva del usuario y el comportamiento del sistema. Generalmente, estas pruebas son escritas en un lenguaje más coloquial y entendible por los stakeholders (aquellos interesados en el negocio, pero que no son necesariamente personal técnico). Una tecnología muy conocida que se utiliza para poder desarrollar pruebas en lenguaje coloquial es Gherkin. 

TDD

Una vez que conocemos el concepto general de esta estrategia, hay que saber qué desafíos presenta utilizarla y cuáles son sus características:  

• Necesitamos un gran conocimiento en desarrollo de pruebas unitarias. 
• Desde una etapa muy temprana del proyecto debemos tener muy en claro qué se va a desarrollar, así como su alcance y sus limitaciones.  
• Las pruebas están enfocadas desde la perspectiva del desarrollador. 
• No se evalúa la calidad de la integración del producto, solo a nivel unitario.  

Además, conviene aclarar que esta estrategia eleva la calidad técnica del producto, es decir, de la salud del código, ya que provee de una gran cobertura de pruebas unitarias, incluso antes de comenzar el desarrollo. Y, ante cualquier cambio, se podría detectar mediante el fallo de estas pruebas.

Flujo de TDD

Existe un flujo básico de tres etapas conocido como «Red, Green, Refactor Cycle», el cual consta de:

1. Escribir una prueba fallida. Esta prueba siempre será fallida porque no hay ningún código desarrollado aún que pueda hacer que la prueba pase de forma exitosa. Sería como tratar de seguir una receta de cocina sin tener ninguno de los ingredientes; seguramente fallaría.
2. Hacer que la prueba pase. Recordemos que, en esta estrategia de desarrollo, quienes dirigen el comportamiento son las pruebas, de tal forma que en esta etapa comenzaremos a escribir el código teniendo como objetivo que las pruebas se ejecuten de forma exitosa, sin enfocarnos en la optimización.
3. Refactorizar. Una vez que hemos pasado la segunda etapa y todos nuestros tests pasan, procederemos a refactorizar el código teniendo en cuenta buenas prácticas y técnicas para brindar calidad de código. Es decir, en esta etapa nos enfocamos en la optimización, siempre teniendo en cuenta que las pruebas sigan pasando.

Este ciclo promete ahorrar mucho tiempo y es bastante adecuado para ser aplicado en metodologías agiles de desarrollo. Eso sí, hay que tener en cuenta que el objetivo principal de esta estrategia no es conseguir cobertura, sino construir un producto de calidad. Es decir, calidad antes que cantidad.

BDD

Tras ver las características de la estrategia de TDD, veremos las características de BDD para poder realizar un análisis crítico de cuál sería su aplicabilidad y poder discernir cuál es la que mejor se ajusta a mi proyecto:

• La característica principal es que se pueden escribir pruebas en un lenguaje común o de negocio (aquí entra en valor Gherkin) describiendo el flujo de un usuario por la aplicación, y cuál es el comportamiento del sistema como respuesta. A estos flujos los llamamos Escenarios de pruebas.
• No requiere que la parte directiva del proyecto tenga una alta formación técnica, ni que tenga conocimiento sobre el desarrollo de pruebas unitarias.
• Las pruebas son de integración, de forma que no tiene como objetivo principal las pruebas unitarias.
• Aparece la fórmula de GIVEN, WHEN, THEN (Dado, cuando, entonces) que nos da una guía de cómo escribir correctamente cada escenario de pruebas.

Fórmula GIVEN, WHEN, THEN

• Given. Aquí describimos las precondiciones necesarias para la ejecución del escenario.
• When. Luego narraremos las acciones que hará el usuario en el sistema.
• Then. Son todas las respuestas esperadas del sistema o validaciones.

Gherkin

Ejemplo de descripción de un escenario de pruebas utilizando Gherkin

Gherkin está diseñado en concreto para resolver un problema muy específico, que es un problema de comunicación entre los perfiles de negocio y los perfiles técnicos a la hora de trabajar bajo un enfoque BDD. Esto es solo la forma en la que se describe la prueba; luego cada uno de los pasos o STEPS estarán asociados al código fuente que realizará las acciones que se describen en este lenguaje de negocio.

La estrategia de BDD surge desde TDD, con lo cual tiene sentido que sus flujos se entrelacen en algún punto.

Flujo de BDD

En BDD el flujo parece ser más complejo, pero realmente es muy similar al visto anteriormente. Hay que tener en cuenta que este ciclo no es de una ejecución, es decir, que se repetirá tantas veces como sea necesario durante el proceso de producción del proyecto.

1. En esta primera instancia se identifican las funcionalidades de nuestro sistema, escritas en la documentación por todo el equipo. Por ese motivo, decimos que las pruebas en BDD no tienen solo la perspectiva del desarrollador. La intención es lograr tener una lista de requisitos priorizada para poder trabajar más libremente en la segunda etapa, una tarea propia del Product Owner.
2. Tras identificar las funcionalidades a probar, a las que llamaremos Features, se comienzan a escribir los escenarios de pruebas. Pueden existir muchos escenarios relacionados con la misma funcionalidad. Nuevamente, estos escenarios de prueba siempre van a fallar porque aún no hay código para respaldar la funcionalidad descrita en lenguaje de negocio. Pero esta prueba nos sirve para acordar con los stakeholder las pruebas que se realizarán, al contrario de lo que ocurre con las pruebas unitarias, que solo pueden ser verificadas por el personal técnico.
3. En esta etapa se escribe el código que respalda la prueba que se ha escrito en Gherkin. Como regla general, se escribe una función por cada STEP del escenario que será ejecutada en el orden en que esté escrito en Gherkin. Es decir, primero se ejecutará la función relacionada con el Given, luego la del When y, por último, la del Then.
4. En esta etapa verificamos que las pruebas estén pasando por completo, ya que en BDD pueden pasar los STEPS individuales, pero fallar la prueba. Debemos asegurarnos de que la prueba completa es exitosa.
5. Por último, daremos el salto a la optimización de código, además de velar por la calidad de código. En BDD es importante pensar en la “reutilización” de los STEPS porque pueden servir para otros escenarios. De esta manera, no será necesario volver a codificar la función relacionada con ese step. Imagina un step que sea “Given el usuario inicia sesión en el sistema”. Probablemente, esa precondición se repita en muchísimos escenarios y, si lo escribo de la forma correcta, puedo reutilizarlo tanto como lo necesite en lugar de duplicar código de forma innecesaria.

BDD vs TDD

Para saber cuál es la mejor aplicación para cada una de estas estrategias, primero debes conocer el sistema que se va a desarrollar. Si es un producto de microservicios, api y full back, probablemente no se debería plantear una estrategia de BDD, ya que no habrá una interacción directa del usuario con tu aplicación, con lo cual no tiene sentido escribir pruebas desde la perspectiva del usuario. En este caso, quizás deberías optar por TDD.

Por otro lado, si el sistema a desarrollar es un sitio web de consultas como podría ser una tienda online o un Home Banking, lo más lógico sería que se plantease una estrategia de BDD, ya que habrá muchos escenarios posibles para probar la interacción del usuario con el sistema.

De todos modos, si no estás muy seguro de qué estrategia se ajusta mejor a tu situación o ves ventajas que no quieres perder de ambas estrategias, es importante que sepas que son compatibles entre ellas. En el ciclo de BDD en el tercer paso o “Etapa de codificación” se puede plantear un ciclo de TDD.

En Hiberus contamos con un equipo de expertos en QA services certificados en ISTQB que pueden ayudarte a configurar tu ecosistema de herramientas QA. ¿Quieres asegurar la calidad de tus proyectos, procesos y productos? ¡Contacta con nosotros!