¿Cuánto tiempo pasas en las pruebas unitarias?

En una empresa para la que solía trabajar, los ejecutivos insistieron en que la cobertura del código con las pruebas unitarias debe ser del 99% o más. Esto resultó en escribir más pruebas que código. Nos llevó literalmente 3 días escribir pruebas para una sola clase que llevó un día implementarlas.

Como resultado, sin embargo, aprendí mucho sobre TDD, herramientas de prueba, prácticas, etc.

En la compañía para la que trabajé después, las pruebas unitarias eran algo desconocido. Era algo que alguien quizás había escuchado antes. Luché por presentarles el concepto de prueba unitaria, pero sin efecto.

Ahora, como autónomo, me pregunto: ¿cuánto tiempo es realmente necesario dedicar a las pruebas unitarias? Siendo en su mayoría desarrollador de iPhone / Android, ¿qué partes del código deben cubrirse en las pruebas?

La cantidad de pruebas unitarias que se necesitan depende de varios factores:

• Tamaño del producto (cuanto mayor sea el proyecto, mayor será la necesidad de incluir al menos algunas pruebas unitarias)
• Nivel de calidad requerido (si está armando rápidamente un software que necesita salir lo más rápido posible y algunos errores menores son aceptables, entonces podría verse obligado a omitir algunas pruebas como pruebas unitarias)
• Tipo de producto (las IU pueden ser probadas por unidad, pero a veces es más fácil omitir las pruebas unitarias en secciones GUI pesadas de un proyecto y, en su lugar, realizar pruebas manualmente)
• Su capacidad / historial de codificación (¿Qué tipo de errores crea normalmente? ¿Son las cosas que normalmente detectan las Pruebas unitarias o las que normalmente encuentra otro tipo de pruebas? Saber esto podría empujarlo a hacer más o menos pruebas unitarias)

En nuestro grupo de productos, apuntamos a un 50-70% de cobertura de código de pruebas unitarias y un 90% + de cobertura de pruebas unitarias y automatización de pruebas combinadas. El tiempo típico presupuestado en las pruebas de unidades de escritura es de aproximadamente 1 día por cada función que demore entre 3 y 4 días en codificar los encabezados. Pero eso puede variar con muchos factores.

La cobertura del código del 99% es excelente. Las pruebas unitarias son geniales. ¿Pero el 99% de cobertura de código solo de pruebas unitarias? Me resulta difícil creer que pueda obtener tanta cobertura solo con las pruebas unitarias .

Para el caso en el que pasó 3 días escribiendo pruebas para una clase que, de lo contrario, tomó 1 día para implementar. No especificó por qué tardó tanto o compartió ningún código. Por especulaciones, supongo que en realidad no estaba escribiendo una verdadera prueba de unidad para su clase, sino que en realidad estaba escribiendo la automatización de la prueba . Y en realidad no hay nada de malo en eso, siempre y cuando reconozca la diferencia entre los dos tipos diferentes de pruebas.

Pero dijiste que los tres días de redacción de exámenes eran solo para una sola clase. Quizás la clase en sí no fue diseñada para pruebas unitarias. ¿La clase implementa la interfaz de usuario? ¿Redes? Archivo de E / S? Si es así, es posible que haya terminado escribiendo más código para probar el tiempo de ejecución de Java que su lógica empresarial que interactúa con el tiempo de ejecución.

TDD te hace pensar en términos de interfaces e interfaces para dependencias. Esa clase única que implementa la interfaz de usuario, la red y el archivo / io para una sola característica podría ser mejor dividida en varias clases: una para la red, otra para el archivo / io y la interfaz de usuario dividida en un diseño de modelo-visor-controlador. Luego puede implementar pruebas apropiadas para cada uno con objetos simulados simples para las dependencias. Por supuesto, todo esto lleva más tiempo. Entonces, en lugar de 1 día para codificar y 3 días para escribir pruebas, este tipo de diseño puede requerir 3 días de codificación y 1 día de pruebas de escritura. Pero el código será mucho más fácil de mantener y reutilizar.

Las pruebas unitarias dan resultado en el momento del mantenimiento. Si planea tener una aplicación de larga duración, pasará más tiempo manteniendo de lo que cree que tendrá ahora (si aún no lo ha intentado, se sorprenderá de cuánto tiempo puede vivir un proyecto exitoso)

Lo que quiere es que si cambia accidentalmente su funcionalidad, sus pruebas se rompen para que encuentre estas cosas lo más rápido posible. A los clientes no les gusta cuando la funcionalidad cambia inesperadamente.

Si está haciendo TDD, escribirá las pruebas al mismo tiempo que el código, cambiando entre ellas cada pocos minutos (o menos). No habrá ningún tiempo distinto dedicado a las pruebas. El uso de TDD hace que sea mucho más fácil saber que tiene una cobertura de prueba sólida.

Si está realizando pruebas unitarias después del hecho, debe escribir las pruebas que le dirán si el código está roto debido a cambios. No confiaría en las métricas de cobertura aquí, sino que iría basado en casos de uso y parámetros a interfaces públicas. En última instancia, esto se basará en su buen gusto y experiencia.

Si no pasará tiempo en las pruebas, pasará aún más tiempo para depurar el código en vivo.
Por lo tanto, pase todo el tiempo que sea necesario para las pruebas, para cubrir todo (o el 99% del código).

Como otros ya notaron, depende en gran medida del tipo de software. La relación de tiempo de prueba / desarrollo 3: 1 que menciona puede ser demasiado para proyectos promedio, pero puede estar perfectamente bien para aplicaciones de misión crítica e incluso puede ser demasiado pequeña para un sistema crítico para la vida.

La cobertura de prueba de unidad de más del 99% es similarmente demasiado esperada en el caso de una aplicación promedio, pero muy poco para un proyecto crítico para la vida.

En mi experiencia, teniendo en cuenta que una parte importante del código de producción es el código de manejo de errores, una cobertura del 80-90% sería suficiente para la mayoría de las aplicaciones, y esto podría requerir aproximadamente la misma cantidad de tiempo dedicado a escribir pruebas unitarias que el código de producción. (Por otra parte, si uno está trabajando seriamente en la forma TDD, los dos están completamente entrelazados para convertirse prácticamente en una sola tarea, por lo que solo se puede adivinar la proporción real).