Hablemos de TDD, BDD y ATDD

¿Que son TDD (Test Driven Development) , BDD (Behavior Driven Development) y ATDD (Acceptance Test-Driven Development)?

Son tres enfoques de desarrollo de software que se centran en la calidad del código y la colaboración entre equipos de desarrollo y partes interesadas. Aunque tienen objetivos similares, difieren en sus enfoques y en las etapas del ciclo de vida del desarrollo en las que se aplican.

TDD

Con este enfoque se escriben primero las pruebas unitarias y luego el código de tal manera que el desarrollo busque siempre pasar las pruebas escritas con anterioridad.

Características

• Necesitamos un gran conocimiento en desarrollo de pruebas unitarias.
• Desde muy temprana etapa del proyecto debemos tener claro qué se desarrollará, así como su alcance y 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.

Proceso de TDD

• Escribir una prueba (unitaria) que falle, porque la funcionalidad aún no está implementada.
• Escribir el código mínimo necesario para que la prueba pase.
• Refactorizar el código si es necesario, manteniendo las pruebas pasando.
• Repetir el proceso para nuevas funcionalidades o cambios.

¿Cuándo se recomienda TDD?

• Microservicios.
• Api.
• Full Back.

BDD

BDD es una metodología que extiende los principios de TDD al colaborar estrechamente con las partes interesadas, como analistas de negocios y desarrolladores, para definir el comportamiento esperado del sistema antes de la implementación.

En las pruebas con BDD podemos usar Gherkin, el cual resuelve un problema específico, que es la comunicación entre las partes funcionales (negocio) y la parte técnica cuando se trabaja en BDD. Gherkin lo que describe son los pasos del comportamiento de un usuario, dados paso están ligados al código que realiza las pruebas.

Ejemplo de escenario escrito en Gherkin

Características

• Se escriben las pruebas en un lenguaje común o de negocio (Gherkin).
• No se requiere alto nivel técnico para el negocio entender las pruebas.
• Las pruebas son de integración (se prueban varios componentes a la vez Back, Front).
• Usa Given, When Then, nos guía como escribir correctamente las pruebas.

Proceso de BDD

• Escribir escenarios de comportamiento en lenguaje natural (como Gherkin) que describan cómo debería comportarse el sistema.
• Convertir estos escenarios en pruebas automatizadas que verifiquen el comportamiento esperado.
• Implementar el código necesario para que las pruebas pasen.
• Refactorizar según sea necesario.

¿Cuándo se recomienda BDD?

• Sitios Web.
• Tiendas web.
• Home Banking.
• App móviles.

ATDD

Es una práctica de desarrollo de software que se basa en la colaboración entre los equipos de desarrollo, los analistas de negocios y los clientes para definir y entender los requisitos del sistema. ATDD se centra en la creación de pruebas de aceptación antes de implementar la funcionalidad, asegurando que el código producido satisfaga los criterios de aceptación definidos por los interesados.

Características

• Se basan en las pruebas de aceptación.
• Integran a técnicos, funcionales (negocio) y usuarios finales.
• Es fácil de entender para los perfiles no técnicos.
• Iteraciones cortas de desarrollos.
• Reduce la ambigüedad en los requisitos.

Proceso de ATDD

• Definir pruebas de aceptación.
• Desarrollar las funcionalidades.
• Verificar las pruebas.
• Lanzar demo.
• Debatir.
• Refactorizar según sea necesario.

¿Cuándo se recomienda ATDD?

• Proyectos dende se requiere una estrecha relación entre los equipos (técnico, negocio, usuarios).
• Proyectos con frecuente cambio de requisitos.
• Donde es crucial cumplir con los requerimientos de los usuarios finales ya que de estos depende el éxito del software o producto.

En resumen, la adopción de TDD, BDD y ATDD puede mejorar la calidad del software, fomentar una mejor colaboración entre equipos y partes interesadas, y garantizar que el software entregado cumpla con las expectativas del usuario final. Sin embargo, es importante recordar que estos enfoques son herramientas y prácticas que deben adaptarse y aplicarse de manera adecuada según las necesidades y el contexto específico de cada proyecto y equipo de desarrollo.