En TDD, ¿cuál es la ventaja de la ejecución de las pruebas, antes incluso de escribir un método vacío?

Soy un TDD practicante y creo que su forma de hacerlo está bien. Viendo la prueba falla, es la parte importante, de no ver el código de error de compilación.

Tratar esto como una versión revisada de la secuencia:

1) Escribir su prueba dentro de un comentario como si los objetos de destino y API ya existe.

2) Escribir sólo lo suficiente de la API de código compilar.

3) Elimine el código de prueba.

4) Ejecutar la prueba y ver que no.

5) solo Escribe el código necesario para conseguirlo para pasar.

6) Ejecutar la prueba y ver que pasa

7) Enjuagar y repetir...

De esa manera usted todavía obtener el beneficio de pensamiento primero la prueba, en lugar de la aplicación en primer lugar.

El flujo de trabajo en Eclipse con JUnit (en contraposición a la de Visual Studio con MSTest) es donde los pasos 1-3 tener más sentido. Paso 3 a continuación, sólo utilizando Eclipse de la Corrección Rápida de la funcionalidad (Ctrl-1) para generar el código auxiliar basado en la prueba de la unidad que acabas de escribir.

DoesntExistYet someObject = new DoesntExistYet();
int resultado = someObject.newMethod("123");
assertEquals(123, resultado);

La solución Rápida para la primera línea crea automáticamente el DoesntExistYet clase (dejando de ir a través de un asistente de primera para ajustar) y la siguiente solución rápida creará newMethod para usted, debidamente averiguar la firma se basa en cómo se utiliza.

Así que con todo lo que automagicification hacer las cosas más fáciles, a continuación, pasar a las otras ventajas de personas han mencionado acerca de ser capaz de spec su API por cómo usarlo.

Creo que todo el mundo le falta un punto crítico--¿cómo SABES que el método todavía no existe? La escritura de una unidad de prueba que se invoca a un método que no debería existir, sin embargo, entonces viendo que no, se verifica que la hipótesis es verdadera. En un lenguaje compilado, se producirá un error de compilación. En un noncompiled idioma, error de ejecución puede ser mucho más rápido que la comprobación de la API. En la mayoría de los idiomas, la herencia y el polimorfismo puede resultar en un método de presente que no se ha registrado en su modelo mental de la API.

En raras ocasiones, puede encontrar que el método en realidad no existe (y IntelliSense puede ayudar a detectar que tan bien), y usted puede darse cuenta de que usted necesita para alterar su forma deseada de la firma. O, usted puede incluso encontrar que usted no necesita escribir ese método (tal vez te escribí la semana pasada, pero se me olvidó).

Ciertamente, usted puede elegir omitir los dos primeros pasos, o incluso prescindir de TDD por completo, pero los pasos que tenía un propósito. Sin embargo, estoy de acuerdo con el sentimiento general de que siempre podemos beneficio de más de la descripción de las razones detrás de estas medidas en la "mejor práctica".

EDIT: a partir De Justin Estándar...

O si usted trabaja en un equipo de desarrolladores y personalmente no escribir el código usted está confiando en. Creo que es una situación bastante común para la mayoría de los desarrolladores.

EDIT: De senfo...

Si usted está teniendo problemas para mantener un seguimiento de los métodos que se han implementado en la base de las clases, me suena como a su jerarquía de herencia es demasiado complejo. Todavía me votaron usted porque estoy de acuerdo en que debo tomar más tiempo para comprobar que un método no ya existen si comienzo con la prueba de la unidad.

@senfo: Demasiada complejidad en la jerarquía de herencia, ciertamente, puede ocurrir, pero ese es un problema diferente con una solución obvia. Incluso si el código existente es perfecto, todavía es valioso para iniciar con una unidad de prueba de que intenta invocar un posiblemente inexistente método, sólo para probar rápidamente a sí mismo de que no existe. Por supuesto, saltarse ese paso es comprensible--yo podría volver a ella en una situación específica donde mi prueba se está portando mal (para comprobar en que situación particular que no estoy invocando algo distinto de lo que acabo de escribir).

Viendo romper esto asegura que usted no tiene la metida de pata en el código de prueba y se construyó una prueba de trabajo desde el principio.

También, el intento de "uso" de una API hace pensar desde una perspectiva diferente (la de la API de usuario), que es casi siempre beneficioso. Es importante hacer esto antes de intentar escribir la API (que será siempre desde la perspectiva de una API de diseñador). Es difícil explicar el valor de usar tu propia Api, pero el término de la industria es fooding de perro.