¿Cuáles son los peligros de la prueba después del desarrollo?

Question

Recientemente me asignaron un proyecto que ya estaba en su mitad. Era el entorno TDD. Todo el mundo estaba siguiendo el principio correcto de Code Unit Test First y el código de implementación más tarde. Pero la pareja estaba haciendo lo contrario, el código de implementación primero y la prueba unitaria más tarde.

Aunque en un debate dicen que de cualquier manera es similar.

¿Cuáles son los posibles problemas que pueden surgir si se sigue primero el código de implementación y la prueba de la unidad?

Answer 1

• Overengineering - es posible que haya escrito más código del que realmente necesita.
• Sesgo: puede escribir pruebas que prueben su implementación en lugar del requisito.
• Las pruebas no conducen su diseño: las pruebas pueden indicar mejoras en el diseño. Con el tiempo, su diseño puede volverse rígido y reacio a los cambios.
• Disminuya la velocidad: su implementación puede tener problemas de comprobación, que solo saldrán a la superficie cuando intente escribir sus pruebas. En ese momento, es posible que se sienta inclinado a arrinconar algo, porque ahora la prueba le impide implementar la próxima función. Es frustrante intentar probar la unidad en un blob inestable ... con más frecuencia terminará con pruebas no exhaustivas (pruebe lo que es fácil y continúe).
• Es posible que las pruebas no se escriban; una vez que su implementación está lista y la ha verificado manualmente, hay una tendencia a omitir las pruebas de la unidad aburrida y saltar a la parte interesante ... escribir más código. Con el tiempo, caos no probado.

Si no es lo suficientemente obvio, pruebe primero FTW!

Answer 2

Escribir las pruebas primero e implementar después asegura que está escribiendo código de implementación que definitivamente pasará las pruebas. Implementar primero y escribir el código de prueba luego corre el riesgo inherente de que tendrá que refactorizar (a veces de manera significativa) su código de implementación para asegurar una cobertura de prueba correcta, que puede llegar a ser costosa dependiendo de qué tan tarde se escribieron esas pruebas.

Experiencia personal, he visto que la mejor productividad/medio provienen de desarrolladores que realizan las pruebas de forma simultánea a la implementación, haciendo lo suficiente para garantizar que los límites de los contratos de interfaz estén correctamente encerrados y sean confiables, dejando pruebas que no causarían rediseño/refactorización importante hacia el final, pero no considerarían el componente completo hasta que se entregara un conjunto completo de pruebas unitarias.

Answer 3

Siempre se recomiendan las pruebas antes de la implementación. Además de corregir errores que pueden haber existido en su software, ayuda a descartar qué partes de su código son necesarias ya que un ingeniero puede tener la tendencia a 'sobrecodificar'.

Lo que siempre me digo a mí mismo "Si estuviera escribiendo software para un piloto automático de avión, ¿qué haría para asegurarme de que esa pieza de software sería nunca?" ¿Esta gente haciendo esto a la inversa pondría a su familia en piloto automático antes de probar el software? Pensar de esta manera ayuda a dar un enfoque disciplinado a la ingeniería de software.