Cómo convencer a un patrocinador del proyecto de que todas las funciones en su código deben tener pruebas unitarias

Question

Las personas no técnicas en la mayoría de los casos no ven ningún valor en la escritura de pruebas unitarias. Solo quieren tener un código básico completo y no gastar dinero y tiempo en cosas como pruebas unitarias. Más tarde, todos los días solo piden arreglar un error más. A los proyectos les faltan fechas límite y todavía no ven valor en buenas pruebas automatizadas.

Answer 1

La mejor manera es no llegar a ser tan técnico con "no gente "técnica". Solo edifíquelo en el tiempo de entrega sin entrar en detalles.

En el otro lado, parece que los plazos del proyecto no eran realistas para realmente construirlo.

Answer 2

Pruebe usar un análogo. Pregúnteles si les gustaría que sus hijos manejen los Volvos o los autos Kit fabricados por un tipo en la calle. La respuesta siempre debería ser el Volvo. Entonces pregunta por qué? La respuesta es más confiable y segura. ¿Cómo lo saben? La respuesta es la prueba. Todos los automóviles son probados hasta el extremo y el costo vuelve a reflejar eso. Si quieren que el software sea lo más confiable posible, necesitan pruebas. (O se convierten en los maniquíes de prueba de bloqueo)

Answer 3

La venta de pruebas unitarias completas después de que el desarrollo ya ha comenzado es muy difícil. Incluso iría tan lejos como para decir que a menudo es imposible. Si no obtiene la aprobación de todas las partes interesadas en el proyecto para una prueba completa de la unidad, debe estar contento con las pruebas unitarias que pueda hacer.

Answer 4

@Craig, pensé en el análogo del coche también, pero creo que la analogía se desmorona, ya que parece que ya hay pruebas presentes en el proyecto y es simplemente una cuestión de grado. En ese caso, la analogía del automóvil se convierte en "¿Te importa si se prueba la luz del domo en el automóvil, siempre que se prueben los sistemas críticos (frenos, faros, transmisión, etc.)?". Como un patrocinador del proyecto acosado que está viendo el proyecto pasar su fecha de finalización, realmente no me importa si la luz del domo se prueba o no.

Answer 5

No es así. Las pruebas no deben ser escritas por separado, por lo que no es necesario contarlas en el cronograma de lo que específicamente programaría "compilar" o "escribir el código". El tiempo dedicado a escribir las pruebas se debe compensar para el momento en que lo salven de todos modos.

Answer 6

Una buena forma de vender el valor de las pruebas unitarias es desde un punto de vista de soporte: si está utilizando un marco de prueba unitario que tiene un tiempo de ejecución que puede implementarse (nUnit es uno), puede tener una "Unidad de ejecución" Prueba el elemento del menú en tu menú de ayuda. Esto puede ejecutar todas las pruebas unitarias y los resultados pueden enviarse al soporte técnico para ayudar a depurar problemas del cliente.

Obviamente hay muchas maneras de vender la mayor estabilidad, pero el soporte técnico es un costo de "dinero real" que la mayoría de los administradores querrían reducir.

Answer 7

Bueno, creo que el problema es que dices "todas las funciones". Todas las funciones no necesitan pruebas unitarias, y algunos argumentarían que la prueba individual de las funciones individuales es totalmente errónea en muchos escenarios.

En su lugar, recomiendo probar unidades reales de "unidades de funcionalidad". En lugar de escribir una única prueba para cada función, escriba una prueba para cada escenario o característica. Además de ahorrarle mucho tiempo y permitirle deslizarse en las pruebas bajo el radar, a menudo es mucho más preciso porque, literalmente, prueba las funciones en la forma en que se usan. Con demasiada frecuencia funcionan las pruebas de unidad de función que no prueban lo correcto o, peor aún, los simulacros de prueba.

Le recomiendo que evite el uso de simulacros en las pruebas a toda costa.El uso de un simulacro esencialmente invalida la prueba porque estás probando cómo funciona en circunstancias idealizadas en lugar de cómo funciona en el mundo real.

Una ventaja adicional es que también obtienes una mejor detección de código muerto. Cualquier código que no esté cubierto por una prueba de alto nivel probablemente no se esté utilizando y pueda eliminarse. Nunca subestimes el valor de eliminar el código muerto.

Answer 8

Acabo de wrote at length sobre este mismo tema.

Para resumir mis argumentos en contra de las quejas más comunes:

La limpieza es invisible para los usuarios; necesitamos agregar nuevas funciones. Los errores producidos constantemente por código desordenado también son visibles para los usuarios. El tiempo invertido en corregir esos errores podría haberse gastado agregando funciones. Cuanto más tiempo permanezcamos en deuda de calidad, más tiempo se necesita para agregar cada nueva característica.

No tenemos tiempo para la limpieza. ¿Prefiere pasar su tiempo solucionando errores generados por el problema en lugar de solucionar el problema? Eso es como golpear malas hierbas todos los fines de semana en lugar de arrancarlas de raíz. La prevención es dieciséis veces más valiosa que la cura.

Los desarrolladores se metieron en este lío; deberían salir de él en su propio tiempo. Si los desarrolladores no hubieran recibido lanzamientos tan rápido como lo hicieron, si no hubieran respondido tan rápido a los comentarios de los primeros usuarios, incluso cuando el producto se transformara en una bestia completamente diferente a su concepción original, no tendríamos nuestros clientes actuales e ingresos. Trabajaríamos para otra empresa, sin quejarnos por el software que creamos.

Atención CEO: el dedo índice impide la resolución. En cambio, desafíe a sus desarrolladores para que reduzcan los informes de errores. Esto se mide fácilmente, por lo que puede realizar un seguimiento del tiempo en comparación con los resultados. Recuerde, los desarrolladores prefieren implementar nuevas características para corregir errores, por lo que si están pidiendo tiempo para corregir errores, es algo serio.

Answer 9

Solo hazlo. Serás más lento al principio ya que estás escribiendo más código y pensando primero en el problema. Pero pasará rápidamente a otros en el proyecto ya que tiene menos errores/errores y su diseño es mejor.

Si diseña el sistema teniendo en cuenta las pruebas, será intrínsecamente un diseño más flexible que uno no comprobable. Luego será más rápido agregar características para en el futuro.