¿Hay alguna diferencia entre TDD y Test First Development (o Test First Programming)?

Question

Ambas ideas me parecen muy similares, pero puede haber diferencias sutiles o exactamente lo mismo, explicadas de diferentes maneras. ¿Cuál es la relación entre TDD y Test First Development / Programming?

Answer 1

Hay una diferencia en términos de cuál es el factor determinante.

¿Tiene una idea vaga de cómo debería ser la clase (o sistema, esto puede suceder a diferentes escalas, por supuesto), luego piense en las pruebas que le dan la forma real? Eso es TDD.

¿Sabe exactamente cuál debería ser la API pública de la clase y simplemente escribe las pruebas antes de la implementación? Ese es el primer desarrollo de prueba.

Mi estilo tiende a ser una mezcla de los dos. A veces es obvio cuál debería ser la API antes de escribir cualquier prueba; en otros casos, la capacidad de prueba realmente impulsa el diseño.

Para decirlo de otra manera, TDD comienza con "¿Qué preguntas quiero hacer?" mientras que la no TDD (ya sea la prueba primero o no) comienza con "¿Qué respuesta quiero dar?"

Answer 2

Básicamente son nombres diferentes que describen lo mismo, 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 Extreme Programming, para el ciclo test-code-refactor. El nombre Test Driven Development ha sido propuesto, y adoptado rápidamente, más tarde, para enfatizar el hecho de que TFD es, y siempre ha sido, más una estrategia de diseño que una estrategia de prueba.

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

Answer 3

Hay muchos términos similares como programación de prueba primero, desarrollo de prueba primero, desarrollo basado en pruebas o incluso diseño basado en pruebas. Es importante aclarar algunos puntos:

1. Probar primera programación (TFP)

El término programación de prueba primero es una práctica recomendada de programación. Fue reintroducido (si no acuñado) por Kent Beck en su libro "Programación extrema explicada": "Escriba pruebas unitarias antes de programar y mantenga todas las pruebas en ejecución en todo momento". Entonces, cuando hablamos de programación de prueba primero, estamos hablando de escribir pruebas unitarias automatizadas por el mismo desarrollador que va a escribir el código para satisfacer esas pruebas. Las pruebas unitarias se acumulan y crean un conjunto de pruebas de regresión automatizado que podría ejecutarse periódicamente.

2. Desarrollo guiado por pruebas (TDD)

Desarrollo impulsado por pruebas (TDD) es el nombre de una metodología introducida por Kent Beck en su libro Test Driven Development by Example. Es un proceso de desarrollo de software, 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 desarrollo basado en pruebas, diseño basado en pruebas o programación basada en pruebas y ... Una cosa es segura: la metodología bien establecida es desarrollo basado en pruebas y la técnica de programación es prueba primero programación. El resto generalmente se refiere a la idea de escribir pruebas antes del código o se refiere erróneamente al desarrollo basado en pruebas o la programación de prueba primero.

Answer 4

TDD = TFD + Refactorización.

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

Answer 5

Históricamente correcto: la primera prueba de programación 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 popularizó Test-First Programming y Test-Driven Development, Test-First Programming pasó a denominarse Test-Driven Development y luego Test-Driven Design siguiendo darse cuenta de que escribir pruebas primero tiene un efecto tremendamente positivo en la arquitectura y el 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
• Desacoplado
• Reutilizable
• Implementable independientemente
• Desarrollable independientemente
• Independientemente Razonable

Las entidades de software solo pueden reutilizarse, probarse, implementarse de forma independiente, desarrollarse de forma independiente o razonarse fácilmente por separado si se desacoplan. Escribir pruebas antes de la implementación real es un método casi a prueba de balas para garantizar un desacoplamiento continuo.

Esta influencia en el diseño y la arquitectura del software se hizo tan importante además de los otros efectos positivos que los creadores consideraron que valía la pena cambiarle el nombre de Programación por prueba a Desarrollo por prueba.

El nombre Test-Driven Development también ayuda a comercializar el método mejor en términos de aceptación y comprensión adecuada porque el nombre Test-Driven Development enfatiza mejor los aspectos holísticos del método que Test-First Programming.

No es históricamente correcto pero útil

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

Programación de prueba primero & # 8230;

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

Desarrollo guiado por pruebas & # 8230;

& # 8230; es un subconjunto específico de la Programación de Prueba Primero que sigue las 3 Leyes de Desarrollo Dirigido por Prueba 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 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 que sea suficiente para pasar la prueba de unidad que actualmente falla.   & # 8212; Robert C. Martin, Las tres leyes del desarrollo basado en pruebas
  

Seguir estas tres reglas te coloca en lo que se llama el ciclo Rojo-Verde-Refactor. 1. Escribes una prueba reprobatoria. 2. Lo haces pasar. 3. Ahora que pasa, puede refactorizar sin piedad antes de escribir la próxima prueba reprobatoria.

Tenga en cuenta que la refactorización de forma segura requiere pruebas. Refactorizar 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? ¿Qué define el comportamiento significativo? Esa es una de las muchas cosas para las que las pruebas son útiles.

Por cierto, si sus pruebas se interponen en la refactorización, sus pruebas son de nivel demasiado bajo, demasiado estrechamente acopladas, y tal vez haya usado demasiadas burlas.

Otros cambios de nombre interesantes en Extreme Programming

• 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 principio, 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 terminar.
• Refactorización continua - > Mejora continua de diseño; La refactorización no es un medio para un fin en sí mismo, sino que sigue un propósito superior.

Son exactamente lo mismo. Ambas referencias escriben primero las pruebas y luego escriben el código que pasará la prueba

TDD (Test Driven Development) es Test First Development / Programming aunque he visto y escuchado que TDD solía significar crear pruebas de unidades repetibles y persistentes (incluso después del código), pero realmente implica que las pruebas se escriben antes del código están probando.

En Test Driven Development: By Example , el autor, Kent Beck , establece claramente que "prueba primero" (TF) es la regla. Entonces TF es el principio que rige TDD. El último es el proceso.

Answer 6

Son exactamente lo mismo. Ambas referencias escriben primero las pruebas y luego escriben el código que pasará la prueba

Answer 7

TDD (Test Driven Development) es Test First Development / Programming aunque he visto y escuchado que TDD solía significar crear pruebas de unidades repetibles y persistentes (incluso después del código), pero realmente implica que las pruebas se escriben antes del código están probando.

Answer 8

En Test Driven Development: By Example , el autor, Kent Beck , establece claramente que "prueba primero" (TF) es la regla. Entonces TF es el principio que rige TDD. El último es el proceso.