¿Cuánto tiempo pasas en las pruebas unitarias?

27

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?

Maggie
fuente
En mi empresa anterior, era Java EE, stripes y struts framework. Como dije, ahora se trata principalmente de desarrollo de iPhone y Android.
Maggie
TDD significa que escribe las pruebas antes del código. Parece que esto fue una prueba "después del hecho", que es otra cosa.
a los gerentes no les importaba la técnica, el líder de mi equipo insistió en TDD. terminó como una combinación de ambos :)
Maggie
Maggie, este artículo te puede interesar: fastcompany.com/magazine/06/writestuff.html
¿Hay alguna métrica para estimar el tiempo? Herramientas para el código JS / .NET?
hellboy

Respuestas:

16

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)
jzd
fuente
10

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.

selbie
fuente
1
Gran respuesta. La mayor parte fue demasiado complicado para probar, tienes razón en eso. Y dividir la clase en varias unidades más pequeñas solo para adaptarse a las mejores pruebas de unidad parece un poco exagerado. Me encantaría adjuntar el código para la clase y las pruebas de acompañamiento, y me encantaría conocer tu opinión, pero no estoy seguro de que me lo permitan. El código no es estrictamente mío, y ya no trabajo para esa compañía, así que me gustaría evitar problemas.
Maggie
2
Es por eso que primero debes escribir las pruebas. Entonces puedes encontrar los lugares naturales donde la lógica se une.
10

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.


fuente
3
Y te ves mal cuando corriges el error A solo para introducir errores B y C.
JeffO
depende de si B y C son atrapados por las pruebas o no
"dedicará más tiempo al mantenimiento de lo que piensa ahora", de hecho, especialmente teniendo en cuenta que los productos de SW suelen sobrevivir a su vida útil planificada, a menudo con mucho.
Péter Török
Realmente no puede "planear" tener una aplicación de larga duración, ya que no puede saber de antemano si el proyecto tendrá éxito o no. Siempre debe considerar eso al presupuestar el tiempo para las pruebas
Eran Galperin
1
@Eran, entonces, ¿debería planear el fracaso para no tener que presupuestar para las pruebas?
4

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.

Sean McMillan
fuente
Sí, para mí esto es cierto (de hecho, generalmente paso entre trabajar en pruebas y trabajar en código de producto cada pocos segundos , no minutos). Por lo tanto, podría decirse que estoy trabajando en pruebas el 100% del tiempo.
Jonathan Hartley
2

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).

ONZ_
fuente
44
¿Por qué la gente tiene tanta paranoia de depuración? Si conoce las herramientas, rara vez se encuentra con un problema que demora más de 5 minutos en depurar. Los problemas que son difíciles de depurar están relacionados principalmente con el enhebrado, pero las pruebas unitarias son inútiles allí de todos modos.
Codificador
3
@Coder, porque las personas tienen experiencia y saben que las pruebas son mucho más útiles que la depuración ciega.
OZ_
2
Depende Las pruebas unitarias suelen ser contraproducentes y añaden una falsa sensación de seguridad. Y en un código bien estructurado no entrará en el problema de "depuración ciega". Tienes un problema, sabes dónde buscar. Si no lo hace, realice una revisión completa del código / diseño. Ver también: programmers.stackexchange.com/questions/86636/…
Codificador
44
Ese es el problema con muchos defensores de TDD, tienen una postura hostil contra la depuración y el diseño, a la vez que confían en las pruebas para encontrar todos los errores. Luego, en el código de producción, las aplicaciones pierden memoria, controladores y fallan en múltiples núcleos, y son como "WTH". TDD es solo una herramienta y, dependiendo de la tarea en cuestión, puede ser muy productivo o muy contraproducente. Intente escribir pruebas unitarias para todos los casos difíciles en la publicación vinculada, y nunca enviará el producto.
Codificador
1
"Si conoce las herramientas, rara vez se encuentra con un problema que demora más de 5 minutos en depurar". - @Coder Me pregunto qué tipo de aplicaciones estás viendo.
Kirk Broadhurst
2

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).

Péter Török
fuente
¿Tienes experiencia en aplicaciones móviles? ¿Cuál sería una relación prueba / desarrollo aceptable para una aplicación móvil simple?
Maggie
@ Maggie, desafortunadamente no. (Entonces, si tuviera que escribir uno, probablemente gastaría más de mi tiempo habitual en pruebas unitarias :-)
Péter Török