Un tema que se suele confundir bastante es sobre las distintas DDs que existen actualmente, por eso quería escribir un poco sobre las diferencias entre las mismas.
Primero, las definiciones
TDD (Test Driven Development) Esto significa escribir una prueba que falla porque la funcionalidad especificada no existe, entonces prosigo con escribir el código más simple que puede hacer pasar la prueba, a continuación, se realiza la refactorización para eliminar la duplicación y el ciclo se repite hasta que la funcionalidad esta lista.
BDD (Behauvior Driven Development) Esto significa crear una especificación/requerimiento ejecutable que falla porque la característica no existe, entonces prosigo con escribir el código más simple que puede hacer pasar la especificación, a continuación, se realiza la refactorización para eliminar la duplicación y el ciclo se repite hasta que la especificación esta lista.
ATDD (Acceptance Test Driven Development) Esto significa que todo el equipo discute en colaboración criterios de aceptación, con ejemplos, y luego los divide en un conjunto de pruebas de aceptación en concreto antes de que comience el desarrollo. ATDD es mas cercano a un proceso mas que una actividad.
Diferencias
Si leemos las definiciones de TDD y BDD parecen que son la misma cosa, la principal diferencia entre ambas esta en el alcance. TDD es una practica de desarrollo (se enfoca en como escribir el código y como debería trabajar ese código) mientras que BDD es una metodología de equipo(Se enfoca en porque debes escribir ese código y como se debería comportar ese código).
En TDD el desarrollador escribe los tests mientras que en BDD el usuario final(o PO o analista) en conjunto con los testers escriben los tests (y los Devs solo generan el código necesario para correr esos tests)
Si vamos a caso de ATDD, la misma es mas cercana a BDD ya que no es una practica, sino una metodología de trabajo, pero la diferencia esta nuevamente en el alcance, a diferencia de BDD, ATDD se extiende aun mas en profundizar la búsqueda de que lo que se esta haciendo no solo se hace en forma correcta, sino que también es lo correcto a hacer. En la gráfica vemos el alcance de ATDD.
Marick, y Elisabeth Hendrickson.
Si comparamos los 3 podemos decir que TDD se ocupa solo a nivel unitario o una porción pequeña de la aplicación en desarrollo, BDD se va a ocupar de que las pruebas sobre la integración de esas unidades a un nivel de negocio para que no solo sean pruebas sino que también sean documentación viva de la aplicación al alcance de cualquier usuario y en su mismo idioma (términos que usa comúnmente). Por ultimo ATDD pasa a participar a nivel de la creación de la US, asegurándose que estamos construyendo lo que el cliente realmente necesita en esta etapa de desarrollo.
Sobre BDD y ATDD, hay un gran debate en cuanto a si estas metodologías son tan diferentes al final de cuentas, pero como pasa con muchos términos en la industria del software, hay quienes lo consideran lo mismo y quienes no. Desde mi lado considero las diferencias planteadas en el actual post. Pueden ver un poco sobre esta discusión de BDD y ATDD aquí y aquí.
BDD vs BDD
Es importante saber que BDD también puede ser considerado para aplicarse a nivel unitario (métodos), ya que no hay nada que evite el uso de BDD para complementar/reemplazar TDD y en lugar de escribir Given-When-Then para pruebas de integración, podemos usar el mismo a nivel unitario y así complementar/reemplazar las pruebas en TDD.
Que tengo usar? TDD, BDD o ATDD?
Puedes usarlos a todos, si bien hay puntos en que se pueden superponer (por ejemplo, la creación de Criterios de aceptacion en ATDD pueden reusarse en los escenarios de BDD) las tres herramientas sirven para utilizar de una forma eficiente durante el sprint en nuestro proyecto agile.
Necesitamos un rápido feedback de nuestro código (TDD), necesitamos saber que las distintas porciones de código desarrollados se integran según lo esperado (BDD) y simplificando bastante el concepto de ATDD, necesitamos saber que estamos construyendo lo correcto (BDD contribuye a esto mismo).
Testing en Español 
Excelente artículo. Muchas gracias. Estoy comenzando con BDD y ATDD y me esta sirviendo mucho.
Saludos.
Me gustaMe gusta
Gracias por tu aportación y tu tiempo, autor. En mi humilde y sincera opinión, me parece una gilipollez como un piano tanto matiz. Son conceptos vacuos. Esto denota cuánto burócrata está aproximándose al mundo del software (o a vivir de él, mejor dicho) y cuánta redundancia y snobismo creciente debemos padecer quienes estamos instruidos en la materia.
Me gustaMe gusta