¿La "implementación obvia" de TDD significa código primero, prueba después?

Mi amigo y yo somos relativamente nuevos TDD y tenemos una disputa sobre la técnica de "Implementación obvia" (de "TDD By Example" de Kent Beck). Mi amigo dice que significa que si la implementación es obvia, debe seguir adelante y escribirla, antes de cualquier prueba para ese nuevo comportamiento. Y de hecho el libro dice:

¿Cómo implementan operaciones simples? Solo impleméntelos.

También:

A veces está seguro de saber cómo implementar una operación. Adelante.

Creo que lo que quiere decir el autor es que primero debe probarlo y luego "simplemente implementarlo", en lugar de "Fake It ('Till You Make It)" y otras técnicas, que requieren pasos más pequeños en la etapa de implementación. Además, después de estas citas, el autor habla de obtener "barras rojas" (fallas en las pruebas) cuando hace "Implementación obvia": ¿cómo puede obtener una barra roja sin una prueba?

Sin embargo, no pude encontrar ninguna cita del libro que diga "obvio" todavía significa prueba primero.

¿Qué piensas? ¿Deberíamos probar primero o después cuando la implementación es "obvia" (según TDD, por supuesto)? ¿Conoces un libro o una publicación de blog que diga eso?

Estoy de acuerdo con su interpretación: sigue siendo Red Green Refactor, solo con el bit Refactor omitido;)

Por lo tanto, escriba primero una prueba fallida, luego implemente la solución obvia en lugar de construir lentamente un diseño de "la más simple posible".

¿Conoces un libro o una publicación de blog que diga eso?

Yo diría que el libro de Beck dice exactamente eso.

Él continúa diciendo

Sin embargo, al usar solo la implementación obvia, estás exigiendo la perfección de ti mismo. Psicológicamente, esto puede ser un movimiento devastador. ¿Qué pasa si lo que escribe no es realmente el cambio más simple que podría hacer pasar la prueba? ¿Qué pasa si tu pareja te muestra una aún más simple? Eres un fracaso! ¡Tu mundo se desmorona a tu alrededor! Tu mueres. Te congelas.

¿Cómo puede hacer que pase la prueba escribiendo el código si no existe antes que el código?

Obviamente no hay reglas duras y rápidas aquí, después de todo, estábamos siendo ágiles para que podamos y debamos adaptarnos a medida que iteramos :)

En parte, dependerá de la operación simple, y a medida que practique TDD más y más, encontrará regularmente cosas que probó mal o que realmente no probó en absoluto, todo es parte de la curva de aprendizaje.

Además, no olvide que TDD le permite probar la interfaz y la implementación antes de confirmarlo en el código activo.

Es posible que sepa cómo implementar algo, pero con qué frecuencia escribe una clase / método perfecto, etc. la primera vez sin algunos ajustes en el camino o revisando el código una o dos veces y seis meses después, cuando cambia algo, puede hacerlo con más confianza y nuevamente en el sandbox de las pruebas.

Por supuesto, las pruebas no significan que usted escriba el código correctamente la primera vez, pero sus cambios son impulsados ​​por la prueba y las pruebas se convierten en el primer cliente del código y, dado que las pruebas son de muy bajo costo y, lo que es más importante, no hay riesgo de cambio Tienes más confianza y libertad mientras te desarrollas.

Si realmente está tratando de obtener una buena cobertura y una mayor calidad, entonces comience con más pruebas para comenzar, a medida que practique TDD más y más, desarrollará su propio sentido del nivel de cobertura que necesita.

He aprendido que para el código trivial no debería haber ninguna prueba unitaria.

ejemplo: Si tiene un método getter / setter de Java que asigna un método a una variable local, una prueba unitaria para esto sería exagerada.

puede ser esto lo que el autor quiere decir con

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."