Test-Driven Development es una metodología de desarrollo de software de prueba primero, lo que significa que requiere escribir el código de prueba antes de escribir el código real que se probará. En palabras de Kent Beck:
El estilo aquí es escribir unas pocas líneas de código, luego una prueba que debería ejecutarse, o incluso mejor, escribir una prueba que no se ejecutará, luego escribir el código que lo hará funcionar.
Después de descubrir cómo escribir un pequeño fragmento de código, ahora, en lugar de simplemente codificar, queremos obtener comentarios inmediatos y practicar "codificar un poco, probar un poco, codificar un poco, probar un poco". Entonces inmediatamente escribimos una prueba para ello.
Entonces, TDD es una metodología técnica de bajo nivel que los programadores usan para producir código limpio que funcione.
Behavior-Driven Development es una metodología que se creó en base a TDD, pero evolucionó a un proceso que no solo concierne a programadores y probadores, sino que trata con todo el equipo y todos los interesados importantes, técnicos y no técnicos. BDD comenzó con algunas preguntas simples que TDD no responde bien: ¿cuántas pruebas debo escribir? ¿Qué debería probar realmente y qué no debería? ¿Cuáles de las pruebas que escribo serán de hecho importantes para el negocio o para la calidad general del producto, y cuáles son solo mi exceso de ingeniería?
Como puede ver, tales preguntas requieren colaboración entre tecnología y negocios. Las partes interesadas comerciales y los expertos en dominios a menudo pueden decirle a los ingenieros qué tipo de pruebas suenan útiles, pero solo si las pruebas son pruebas de alto nivel que tratan aspectos comerciales importantes. BDD llama a tales pruebas comerciales "ejemplos", como en "dime un ejemplo de cómo esta característica debería comportarse correctamente", y se reserva la palabra "prueba" para verificaciones técnicas de bajo nivel, tales como validación de datos o pruebas de integraciones API. La parte importante es que, si bien las pruebas solo pueden ser creadas por programadores y evaluadores, todo el equipo de entrega puede recopilar y analizar ejemplos , por diseñadores, analistas, etc.
En una oración, una de las mejores definiciones de BDD que he encontrado hasta ahora es que BDD se trata de "tener conversaciones con expertos en el dominio y usar ejemplos para obtener una comprensión compartida del comportamiento deseado y descubrir incógnitas". La parte del descubrimiento es muy importante. A medida que el equipo de entrega recopila más ejemplos, comienzan a comprender el dominio comercial cada vez más y, por lo tanto, reducen su incertidumbre sobre algunos aspectos del producto con los que tienen que lidiar. A medida que disminuye la incertidumbre, aumenta la creatividad y la autonomía del equipo de entrega. Por ejemplo, ahora pueden comenzar a sugerir sus propios ejemplos que los usuarios comerciales no creían que fueran posibles debido a su falta de experiencia en tecnología.
Ahora, tener conversaciones con los expertos en negocios y dominios suena genial, pero todos sabemos cómo eso a menudo termina en la práctica. Comencé mi viaje con la tecnología como programador. Como programadores, se nos enseña a escribir código: algoritmos, patrones de diseño, abstracciones. O, si eres diseñador, te enseñan a diseñar—Organizar información y crear hermosas interfaces. Pero cuando conseguimos nuestros trabajos de nivel de entrada, nuestros empleadores esperan que "entreguemos valor a los clientes". Y entre esos clientes puede estar, por ejemplo ... un banco. Pero no podía saber casi nada sobre banca, excepto cómo disminuir eficientemente el saldo de mi cuenta. Por lo tanto, tendría que traducir de alguna manera lo que se espera de mí en código ... Tendría que construir un puente entre la banca y mi experiencia técnica si quiero aportar algún valor. BDD me ayuda a construir ese puente sobre una base estable de comunicación fluida entre el equipo de entrega y los expertos en el dominio.
Aprende más
Si quieres leer más sobre BDD, escribí un libro sobre el tema. "Escribir excelentes especificaciones" explora el arte de analizar los requisitos y lo ayudará a aprender cómo construir un excelente proceso de BDD y a usar ejemplos como parte central de ese proceso. El libro habla sobre el lenguaje omnipresente, la recopilación de ejemplos y la creación de las llamadas especificaciones ejecutables (pruebas automatizadas) a partir de los ejemplos, técnicas que ayudan a los equipos de BDD a entregar un excelente software a tiempo y dentro del presupuesto.
Si está interesado en comprar "Escribir excelentes especificaciones" , puede ahorrar un 39% con el código de promoción 39nicieja2 :)