unit-testing - test - pruebas unitarias interfaz
Proporción del tiempo dedicado a la codificación frente a la prueba unitaria (3)
Encuentro que varía mucho dependiendo del código con el que está trabajando: al escribir algo desde cero, impulsado por la prueba, probablemente lleve la misma cantidad de tiempo implementar la función como sin pruebas, pero ahorra más tiempo en la cantidad de los errores que se encontrarán y con qué facilidad puede mantener y extender esa base de código. Se podría argumentar que es más rápido en este caso escribir con pruebas, ya que se evitan esos momentos en los que el código simplemente no se comporta como se esperaba y hay que usar un depurador para descubrir qué está pasando, a través de un cambio conjunto que TDD típicamente permitiría.
Cuando intenta implementar funciones sobre una base de código "heredada" existente (como Michael Feathers definiría el legado), a menudo lleva mucho más tiempo implementar la característica con pruebas que sin ella, debido a la cantidad de cuidadosa refactorización que debe hacerse antes de escribir pruebas normalmente es posible. En este caso, las pruebas de las unidades de escritura seguirán siendo beneficios a largo plazo, pero debe considerar si ese beneficio a largo plazo está justificado por el costo inmediato.
En general, siempre presionaría por alguna forma de prueba automatizada, ya sea de unidad o funcional, a pesar de los costos adicionales para las bases de código heredado. Sin él, es probable que se encuentre atascado con una base de código que es muy difícil de mantener y requiere pruebas manuales constantes y repetitivas para garantizar que continúe funcionando, con frecuentes regresiones.
¿Cuál es una estimación típica para las pruebas de unidad de codificación dado un cálculo para la codificación de nuevas funcionalidades? ¿Es diferente para las estimaciones mantener el código?
Mi tiempo es aproximadamente igual entre el tiempo para las pruebas unitarias y el tiempo para el código funcional.
Algunas personas lo verían y dirían que es una pérdida de tiempo, pero si tu única otra opción es ejecutar la aplicación y recorrer todos los caminos posibles que la aplicación puede tomar, entonces el tiempo dedicado a las pruebas unitarias es en realidad menor que el tiempo que gastaría en pruebas de desarrollo. Por supuesto, si no haces muchas pruebas de desarrollo, pasarás el tiempo solucionando los errores que surgen de la garantía de calidad.
De cualquier manera, el tiempo dedicado a escribir la prueba unitaria ahorra tiempo del monto que gastaría en el proyecto.
Cuando llega el momento de mantener el código (pequeños cambios, pequeñas adiciones en la funcionalidad), puede haber una diferencia. Si el código que se está modificando ya está completamente cubierto y sus cambios no requieren cambios en las pruebas, entonces su tiempo es 0. De lo contrario, obviamente no lo es, probablemente esté más cerca de ser igual nuevamente.
Pero, su ahorro de tiempo en el tiempo de prueba es MUCHO más grande; ya ha creado las pruebas para cubrir el resto del código, por lo que descubriría cualquier cambio incidental que surja de su cambio sin ningún código nuevo o caminando la aplicación.
Yo diría que paso cerca del 50% de las pruebas de unidad de codificación de tiempo. es difícil medir su ganancia, excepto por experiencia personal, pero me parece que ofrece 3 beneficios principales:
- lo obliga a pensar más en su diseño, y tiende a escribir mejor código como resultado
- le permite volver a factorizar / mantener muchos meses / años en el futuro sin tener miedo, romperá todo
- Reduce el tiempo total del proyecto gastado, ya que no pierdes el tiempo cazando errores triviales que las pruebas unitarias habrían atrapado