Siempre he visto la recomendación de que primero deberíamos escribir pruebas unitarias y luego comenzar a escribir código. Pero siento que ir hacia el otro lado es mucho más cómodo (para mí): escribir código y luego las pruebas unitarias, porque siento que tenemos mucha más claridad después de haber escrito el código real. Si escribo el código y luego las pruebas, es posible que tenga que cambiar mi código un poco para que sea comprobable, incluso si me concentro mucho en crear un diseño comprobable. Por otro lado, si escribo las pruebas y luego el código, las pruebas cambiarán con bastante frecuencia a medida que el código se forma.
Como veo muchas recomendaciones para comenzar a escribir pruebas y luego pasar a la codificación, ¿cuáles son las desventajas si lo hago de otra manera: escribir código y luego las pruebas unitarias?
Respuestas:
El rojo es la respuesta. Rojo es lo que obtienes del ciclo refactor rojo-verde de TDD que no puedes obtener, prueba al final. Primero, escribe una prueba reprobatoria. Míralo fallar. Ese es tu rojo, y es importante. Dice: Tengo este requisito y sé que mi código no lo cumple. Entonces, cuando va al paso 2 (verde), sabe, con la misma certeza, que su código ahora cumple con ese requisito. Sabe que ha cambiado su base de código de tal manera que satisfaga el requisito.
Los requisitos (pruebas) desarrollados después del código, basados en el código, lo privan de ese tipo de certeza, esa confianza.
fuente
Si escribe el código, y luego las pruebas, es demasiado fácil caer en la trampa de escribir las pruebas para que el código pase, en lugar de escribir las pruebas para garantizar que el código cumpla con la especificación.
Dicho esto, definitivamente no es la única forma de hacer las cosas, y no hay una "mejor" forma de desarrollar software. Si pone mucho trabajo por adelantado en el desarrollo de casos de prueba, no sabrá si su arquitectura propuesta tiene algún defecto hasta mucho después, mientras que si desarrolló el código primero, se encontrará con ellos antes y podrá rediseñarlos con menos hundimiento. esfuerzo.
fuente
En realidad, las personas se obsesionan con TDD se trata de pruebas, aunque se olvidan de las otras dos letras en el acrónimo. Algo que se puede leer aquí: TDD sin T o TDD no se trata de pruebas .
La cosa es que he aprendido una gran cantidad de otras cosas que están estrechamente unidas con TDD. No importa si prueba primero: lo que importa es pensar en el diseño de software .
Para poder incluso escribir pruebas unitarias "de la manera correcta", es decir, para que estén aisladas, sean rápidas y automatizadas, notará que se necesita un replanteamiento acerca de cómo organizar su código de una manera que sea más fácil. Probar.
Personalmente, aprendí los principios SÓLIDOS sin saber que había tal cosa escrita. Esto se debe a que escribir pruebas unitarias me obligó a reescribir clases para que no se vuelvan demasiado complejas para probar. Condujo a cosas como:
Aunque no hago primero las pruebas todo el tiempo, sí sigo los buenos principios y prácticas de OO que empiezas a seguir, solo para facilitar un poco las pruebas. Ahora no estoy escribiendo código por sí mismo. Escribí el código para que pueda probarse fácilmente o, lo que es más importante; De fácil mantenimiento .
fuente
Todas las otras respuestas son buenas, pero hay un punto que no se mencionó. Si escribe la prueba primero, se asegura de que las pruebas se escriban. Es tentador, una vez que ha escrito el código de trabajo, omitir las pruebas y simplemente verificarlo a través de la interfaz de usuario. Si tiene la disciplina de tener siempre una prueba fallida antes de escribir el código, puede evitar esta trampa.
fuente
Si escribe sus pruebas primero, le da otra oportunidad de pensar en su diseño, antes de que ese diseño se "eche en piedra".
Por ejemplo, puede pensar que necesita un método que tome un determinado conjunto de parámetros. Y si escribió el código primero, lo escribiría de esa manera y haría que la prueba se ajustara a los parámetros especificados. Pero si escribe la prueba primero, puede pensar "espere un minuto, no me gustaría usar este parámetro en el código de la línea principal, así que tal vez debería cambiar la API".
fuente
Hay una muy buena razón para esto.
Si dices "haz lo que se siente bien", la gente hace las cosas más tontas y locas.
Si dices "escribe las pruebas primero", al menos las personas podrían intentar hacer lo correcto.
Por lo general, una prueba pésima y un diseño que tiene que ser modificado para ser comprobable.
Sin embargo, eso es solo un "por lo general". Algunas personas desarrollan los diseños y las pruebas en paralelo. Algunas personas implementan códigos comprobables y escriben pruebas sin reprocesos.
La regla "Prueba primero" está específicamente allí para enseñar e instruir a las personas que no tienen ni idea.
De manera similar, se nos dice que siempre miremos "en ambos sentidos" antes de cruzar la calle. Sin embargo, en realidad no lo hacemos. Y no importa Vivo en un país con volante a la derecha y solo necesito mirar a la izquierda al comenzar a cruzar.
Cuando visito un país con el volante a la izquierda, mirar hacia la izquierda solo podría hacer que me maten.
Las reglas se establecen muy fuertemente por una razón.
Lo que haces es tu propio problema.
fuente
el punto de escribir la prueba primero es que te hace pensar en
si está haciendo algo simple, probablemente no importa cuál escriba primero (aunque es bueno cultivar el hábito de probar primero) ya que la prueba será simple y la interfaz será obvia
pero TDD se amplía a pruebas de aceptación, no solo pruebas unitarias, y luego la interfaz deja de ser trivial.
fuente
Primero, si no escribe sus pruebas primero, entonces no está haciendo Test Driven Development (TDD). Los beneficios son numerosos y, a menudo, difíciles de creer hasta que lo practique varias veces. Estos son los beneficios que he recibido haciendo TDD sobre el desarrollo tradicional:
Libros: Beck, K. Test-Driven Development by Example
Buen ejemplo: http://jamesshore.com/Blog/Lets-Play/
fuente
Cuando escribe una prueba, ¿cómo sabe que detectará una condición de falla? La respuesta es "prueba la prueba". Lo que debe hacer es escribir primero la prueba, verla fallar y solo verla pasar cuando la unidad bajo prueba se haya codificado con éxito (el ciclo rojo / verde / refactor mencionado en una de las otras respuestas).
Escribir el código primero y luego la prueba deja abierta la pregunta de si la prueba mostraría un fallo honesto.
Recuerde que sus pruebas expresan especificación. Si tiene que revisar sus pruebas a medida que su código se "forma", sugiere que sus especificaciones están cambiando. Eso puede o no ser algo bueno. Podría significar que su comprensión del problema no fue inicialmente correcta. Por otro lado, podría significar que está probando "cómo" la unidad está haciendo su trabajo en lugar de lo que se supone que está logrando.
fuente