24 votos

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

Veo un montón de TDD profesionales después de este ciclo:

1) Escribir su prueba como si el destino los objetos de la API y ya existe.

2) Compilar la solución y ver descanso.

3) solo Escribe el código necesario para llegar a compilar.

4) Ejecutar la prueba y ver si falla.

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

6) Ejecutar la prueba y ver que pasa

7) Refactorizar

¿Cuál es la ventaja de los pasos 1 y 2? Con el Ide como Visual Studio, esta es realmente molesto, ya que intellisense saltos por todo el lugar tratando de adivinar los métodos y atributos que no están allí.

Por lo general comienzan en el paso 3, con todos mis métodos de lanzar NotImplementedException, y esto parece perfectamente bien para mí, pero tal vez me estoy perdiendo algo.

Edición de aclaración: esto no es una pregunta ¿por qué yo debería ver una prueba de errores antes de que pase; que está cubierto en el paso 3 en adelante, y se hace total sentido. Mi pregunta es ¿por qué incluso antes de que la gente va a llamar a un método en la prueba de la unidad que no existe en la API (por lo tanto VS mostrará una línea ondulada de color rojo, o la pintura de todo el nombre de método roja, etc) y tratar de compilar todos modos. Para mí, el hecho de que VS me está diciendo que el método no existe es lo suficientemente bueno.

19voto

Cory Foy Puntos 5181

A continuación, tratar por escrito el nombre del método en primer lugar. Me encuentro escribiendo la primera prueba y los métodos, que me obliga a pensar realmente acerca de la API, y yo soy libre para cambiar fácilmente los nombres sin tener que preocuparse de código que ya ha sido escrito. Mi sugerencia sería la de tratar de no seguir las reglas, y monitorear lo que sucede. Si usted encuentra que las causas de los problemas, cambiar de nuevo. Y si no, tienes una nueva forma de trabajar ahora.

Recuerde también que cuando usted está aprendiendo acerca de las cosas, por lo general usted necesita un conjunto claro de reglas para darle contexto. Como usted comienza a moverse desde el Principiante hasta el más avanzado, usted ganará más el contexto y ser capaz de hacer ajustes. Me suena como que es donde está.

12voto

Justin Standard Puntos 15312

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.

10voto

Brian Deacon Puntos 4185

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.

10voto

Rob Williams Puntos 6316

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).

3voto

Lawrence Dol Puntos 27976

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.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X