¿Cómo mantienes la disciplina cuando haces TDD?

Question

Cuando estoy entusiasmado con una nueva característica que estoy a punto de implementar o sobre un error que acabo de "entender", existe la necesidad de saltar al código y piratear. Se necesita un cierto esfuerzo para evitar hacer eso y escribir primero la prueba correspondiente. Más tarde, la prueba a menudo resulta ser trivial, pero antes de escribir todavía está la idea detrás de una cabeza: "¿Tal vez puedo omitir esta, esta vez?" Idealmente me gustaría tener ganas de escribir una prueba, y solo entonces, tal vez, el código :)

¿Qué método (o forma de pensar o truco mental o política de auto recompensa o lo que sea) usas para ayudar mantener la disciplina? ¿O lo practicas hasta que se siente natural?

Answer 1

Me gustan los comentarios instantáneos de la prueba, eso es suficiente recompensa para mí. Si puedo reproducir un error en una prueba que es una buena sensación, sé que voy en la dirección correcta en lugar de adivinar y posiblemente perder el tiempo.

Me gusta trabajar en Test-First porque siento que me mantiene más a tono con lo que el código realmente está haciendo en lugar de adivinar basándose en un modelo mental posiblemente inexacto. Ser capaz de confirmar mis suposiciones de forma iterativa es una gran recompensa para mí.

Answer 2

wear a green wristband

Answer 3

1) Usted par con otra persona en su equipo de. Una persona escribe la prueba, la otra implementa.

Se llama emparejamiento "ping-pong".

Hacer esto le obligará a discutir el diseño y averiguar qué hacer.

Tener esta discusión también hace que sea más fácil ver qué pruebas va a necesitar.

2) Cuando trabajo por mi cuenta, me gusta probar fragmentos de código de forma interactiva. Simplemente los escribo en el prompt de ruby. Cuando estoy experimentando así, a menudo necesito establecer algunos datos para experimentar y algunas declaraciones impresas para ver cuál es el resultado.

Estos pequeños, de usar y tirar experimentos independientes son por lo general:

• una forma rápida de establecer la viabilidad de una aplicación, y
• buen lugar para comenzar a formalizar en una prueba.

Answer 4

Encuentro que escribir pruebas me ayuda a esbozar mi enfoque del problema en cuestión. A menudo, si no puedes escribir una buena prueba, significa que no has pensado lo suficiente acerca de qué es lo que se supone que debes hacer. La satisfacción de estar seguro de que sé cómo abordar el problema una vez que se escriben las pruebas es bastante útil.

Answer 5

Te avisaré cuando encuentre un método que funcione. :-)

Pero en serio, creo que su comentario de "practicar hasta que se siente natural" casi le da en el clavo. Una prueba de 4 líneas puede parecer trivial, pero mientras lo que está probando represente un punto de falla real, entonces vale la pena hacerlo.

Una cosa que he encontrado útil es incluir validación de cobertura de código como parte del proceso de compilación. Si no escribo las pruebas, la compilación se quejará de mí.Si continúo fallando al escribir las pruebas, la construcción de integración continua tendrá un "error de salida" y todos los que estén cerca oirán el sonido que he conectado a la notificación de "compilación rota". Después de unas semanas de "Buen dolor ... ¿Lo rompió de nuevo?", Y comentarios similares, pronto comencé a escribir más pruebas para evitar la vergüenza.

Otra cosa (que solo se me ocurrió después de haber enviado la respuesta la primera vez) es que una vez que realmente adquirí el hábito de escribir pruebas primero, obtuve un gran refuerzo positivo por el hecho de que podía enviar errores -fixias y características adicionales con mucha más confianza de la que podía en mis días de prueba previa automática.

Answer 6

Creo que la parte importante de mantenerse bajo control en lo que respecta a TDD es tener el proyecto de prueba configurado correctamente. De esa manera, agregar un caso de prueba trivial es ciertamente trivial.

Si para agregar una prueba primero necesita crear un proyecto de prueba, luego averiguar cómo aislar componentes, cuándo burlarse de cosas, etc., etc. se convierte en una cesta demasiado dura.

Supongo que vuelve a tener pruebas unitarias totalmente integradas en su proceso de desarrollo.

Answer 7

Cuando comencé a hacer TDD alrededor de 2000, se sentía muy antinatural. Luego vino la primera versión de .net y el puerto JUnit de NUnit, y comencé a practicar TDD en el nivel Shu (de Shu-Ha-Ri), lo que significaba probar (primero) todo, con las mismas preguntas que las tuyas.

Unos años más tarde, en otro lugar de trabajo, junto con un desarrollador senior competente y dedicado, tomamos las medidas necesarias para alcanzar el nivel Ha. Esto significaba, por ejemplo, no protagonizar ciegamente el informe de cobertura, pero la pregunta "¿es realmente útil este tipo de prueba y agrega más valor de lo que cuesta?".

Ahora, en otro lugar de trabajo, junto con otro gran colega, siento que estamos dando nuestros primeros pasos hacia el nivel Ri. Para nosotros, eso significa actualmente un gran enfoque en BDD/historias ejecutables. Con los que están en el lugar verificando los requisitos en un nivel superior, me siento más productivo, ya que no necesito (re) escribir un montón de pruebas unitarias cada vez que la interfaz pública de una clase necesita cambiar, reemplazar una llamada estática con un método de extensión, y así sucesivamente.

No me malinterpreten, las pruebas de la clase TDD habituales todavía se utilizan y nos proporcionan un gran valor. Es difícil expresarlo con palabras, pero somos mucho mejores en "sentir" y "sentir" qué pruebas tienen sentido y cómo diseñar nuestro software, de lo que era capaz hace diez años.

Answer 8

La manera más fácil que he encontrado es usar mucho TDD. En algún punto, escribir código sin pruebas unitarias se convierte en una actividad muy, muy nerviosa.

Además, trate de concentrarse en la interacción o las pruebas de comportamiento en lugar de las pruebas basadas en el estado.