Son básicamente nombres diferentes que describen la misma cosa - bueno, de hecho cinco nombres, ya que la última D puede significar tanto Diseño como Desarrollo.

Test First fue el término utilizado originalmente, especialmente en el contexto de la Programación Extrema, para el ciclo test-code-refactor. El nombre Test Driven Development ha sido propuesto - y rápidamente adoptado - más tarde, para enfatizar el hecho de que TFD es-y siempre ha sido-más una estrategia de diseño que una prueba estrategia.

Obviamente hoy en día algunas personas tienen diferentes connotaciones para esos dos términos, pero esa no era la intención detrás de su existencia, y yo no confiaría en que sea de conocimiento común (porque no lo es). De hecho, preferiría ver el término TFD como obsoleto.

Hay muchos términos similares como programación test-first, desarrollo test-first, desarrollo test-driven o incluso diseño test-driven. Es importante aclarar algunos puntos:

1. Prueba Primera programación (TFP)

El término test-first programming es una buena práctica de programación. Fue reintroducido (si no acuñado) por Kent Beck en su libro "Extreme Programming Explained": "Escribir pruebas unitarias antes de programar y mantener todas las pruebas funcionando en todo momento". Tan, cuando se habla de programación test-first estamos hablando de escribir pruebas unitarias automatizadas por el propio desarrollador que va a escribir el código para satisfacer esas pruebas. Las pruebas unitarias se acumulan y construyen un conjunto de pruebas de regresión automatizada que se podría ejecutar periódicamente.

2. Desarrollo impulsado por Pruebas (TDD)

Test-driven development (TDD) es el nombre de una metodología introducida por Kent Beck en su libro "Test Driven Development by Example". Es un desarrollo de software proceso, no se trata solo de escribir pruebas antes del código. Todo el libro está tratando de explicarlo por patrones, flujos de trabajo, cultura, etc. Un aspecto importante es el énfasis en la refactorización.

Algunas personas usan los términos test-first development, test-driven design, o test-driven programming and ... Una cosa es segura: la metodología bien establecida es el desarrollo basado en pruebas y la técnica de programación es la programación basada en pruebas. El resto se refieren generalmente a la idea de escribir pruebas antes del código o referirse erróneamente al desarrollo basado en pruebas o a la programación basada en pruebas.

TDD = TFD + Refactorización.

Cuando haces TFD , aplicas alguna refactorización para hacer que el código sea más genérico y robusto.

Históricamente Correcto: La Programación Basada en Pruebas y el Desarrollo Basado en Pruebas significan Lo Mismo con un Nombre Mejorado

En el contexto de XP (Extreme Programming), que es el proceso de desarrollo de software que hizo popular la Programación Basada en Pruebas y el Desarrollo Basado en Pruebas, la Programación Basada en Pruebas fue renombrada a Desarrollo Basado en Pruebas y luego Diseño Basado en Pruebas tras darse cuenta de que escribir pruebas primero tiene un efecto diseño de un sistema de software.

Esta influencia en la arquitectura y el diseño es consecuencia de sinónimos más o menos sorprendentes:

• Comprobable
• Disociado
• Reutilizable
• Desplegables de forma independiente
• Desarrollable de forma independiente
• Independientemente Razonable

Las entidades de software solo pueden reutilizarse, probarse, desplegarse de forma independiente, desarrollarse de forma independiente o razonarse fácilmente por separado si están desacopladas. Pruebas de escritura antes de la implementación real es un método casi a prueba de balas para garantizar el desacoplamiento continuo.

Esta influencia en el diseño y la arquitectura de software se volvió tan importante además de los otros efectos positivos que los creadores encontraron que valía la pena cambiarlo de Programación de Prueba a Desarrollo Impulsado por Pruebas.

El nombre Test-Driven Development también ayuda a la comercialización del método mejor en términos de aceptación, así como la comprensión adecuada porque el nombre Test-Driven El desarrollo enfatiza mejor en los aspectos holísticos del método que la Programación de Prueba Primero.

No Es Históricamente Correcto pero Útil

Aunque históricamente no es correcto, encuentro la siguiente distinción muy útil:

Prueba-Primera programación {

} es cualquier método en el que las pruebas para el código bajo prueba se escriben antes del código bajo prueba.

Desarrollo basado en pruebas {

} es un subconjunto específico de la Programación Test-First que sigue las 3 Leyes de Desarrollo basado en Pruebas como lo describe Robert C. Martin:

1. No puede escribir ningún código de producción hasta que haya escrito primero una prueba unitaria fallida.
2. No se puede escribir más de una prueba unitaria de la que es suficiente para fallar, y no compilar está fallando.
3. No puede escribir más código de producción del suficiente para pasar la prueba unitaria que falla actualmente. -Robert C. Martin, Las Tres Leyes del Desarrollo Basado en Pruebas{[46]]}

Seguir estas tres reglas te pone en lo que se llama el ciclo Rojo-Verde-Refactor. 1. Escribes un examen fallido. 2. Haz que pase. 3. Ahora que pasa, puede refactorizar sin piedad antes de escribir la siguiente prueba fallida.

Tenga en cuenta que la refactorización segura requiere pruebas. Refactorización significa cambiar la estructura del código fuente sin cambiar el comportamiento significativo. Pero, ¿cómo sabemos que no hemos alterado accidentalmente un comportamiento significativo? Lo que define ¿comportamiento significativo? Esa es una de las muchas cosas para las que las pruebas son útiles.

Por cierto, si sus pruebas se interponen en el camino de la refactorización, sus pruebas son demasiado de bajo nivel, demasiado estrechamente acoplados, y tal vez usted ha utilizado demasiada burla.

Otros nombres interesantes en la Programación Extrema

• Integración continua - > Entrega Continua - > Despliegue continuo; Estrictamente hablando significan cosas diferentes, sin embargo, en el espíritu de XP, significaba Despliegue Continuo desde el y cuando la gente se subió al carro, se dio cuenta de que la integración se tomó demasiado literalmente y la gente se detuvo antes de que terminaran.
• Refactorización Continua -> Mejora Continua del Diseño; La refactorización no es un medio para un fin en sí mismo, sino que sigue un propósito superior.
• Semana de 40 horas -> Ritmo sostenible (Leyenda urbana: Este cambio de nombre ocurrió después de las protestas de los desarrolladores de software franceses.)

Son exactamente la misma cosa. Ambas pruebas de escritura de referencia primero, luego escribir el código que pasará la prueba

TDD (Test Driven Development) es Desarrollo/Programación de Prueba Primero, aunque he visto y oído que TDD solía significar crear pruebas unitarias persistentes y repetibles (incluso después del código), pero en realidad implica que las pruebas se escriben antes del código que están probando.