¿Cuánto tiempo deberíamos pasar generalmente escribiendo pruebas unitarias para una nueva característica o corrección de errores?

Cuando tengo que implementar una nueva característica o corregir un error, generalmente trato de recrear la situación con una prueba. A veces paso alrededor de 3 horas creando accesorios y escribiendo la prueba. La implementación de la función real o la corrección de errores lleva menos de 1 hora.

¿Alguien más pasa al menos 3 veces más tiempo para escribir una prueba en comparación con la implementación real de una función o la reparación de un error? ¿Cuál es la proporción aceptable de tiempo dedicado a escribir pruebas para escribir código?

Varía en la complejidad del error o característica. Recuerdo un proyecto que una vez tuvo un estimado de desarrollo de 1.5 semanas ... y un estimado de prueba de 3 meses. El cambio de código fue pequeño, un puñado de líneas aquí y allá, pero afectó a varios componentes de un sistema de seguro de varias maneras, por lo que tuvo que probarse muy a fondo. Otra vez hubo un error que involucraba un paréntesis en el lugar equivocado. Tardó 2 horas para encontrarlo, 2 segundos para solucionarlo, pero aproximadamente una semana para probar docenas de escenarios que pueden haber sido afectados por el cambio en la lógica.

En general, no me preocupa la relación entre el tiempo dedicado a la codificación y el tiempo dedicado a las pruebas porque simplemente no hay forma de ser precisos. Me parece que en algunos proyectos, aparece una relación relativa al proyecto que generalmente es estándar (para el proyecto), pero incluso entonces eso puede cambiar más adelante.

Pase todo el tiempo que sea necesario para decir con confianza que el código funciona correctamente.

¿Qué tal si pasa el tiempo suficiente escribiendo las pruebas hasta que demuestre que la función funciona según lo previsto o que el error se ha solucionado correctamente?

Cada situación será diferente; No puede haber algún tipo de relación. Algunas pruebas tomarán una décima parte del tiempo de implementación, otras tomarán cientos de veces más tiempo.

Una vez hice un descubrimiento después de introducir pruebas unitarias en un proyecto. El resultado: el tiempo dedicado a escribir pruebas fue aproximadamente un 40% más que el tiempo dedicado a la implementación. Pero no buscábamos una cobertura total allí, y era un proyecto bien establecido con una estructura y convenciones sólidas.

Yo diría que la codificación de tiempo frente a las pruebas de unidad de escritura de tiempo debería ser aproximadamente igual. Quizás un poco más a veces. Eche un vistazo a este artículo sobre la relación SO del tiempo dedicado a la codificación frente a las pruebas unitarias

¿Estás contando bien? Para hacer un recuento preciso de cuánto tiempo pasas en las pruebas, necesitas escribir el código sin la prueba.

Si realmente le tomó tres horas escribir la prueba y uno escribir el código para que pase, es posible que tarde más de 5 horas en solucionar el mismo error sin escribir las pruebas.

Sí, a menudo paso mucho más tiempo en la prueba que el código de reparación real.