unit-testing - tutorial - pruebas unitarias java eclipse
Cómo convencer a un patrocinador del proyecto de que todas las funciones en su código deben tener pruebas unitarias (9)
Las personas no técnicas en la mayoría de los casos no ven ningún valor en escribir 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.
@ Craig, también pensé en el análogo del coche, 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.
Acabo de escribir extensamente sobre este mismo tema.
Para resumir mis argumentos contra las quejas 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 corrigiendo 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 los 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 de su concepción original, no tendríamos nuestros clientes e ingresos actuales. . Trabajaríamos para otra empresa, sin quejarnos por el software que creamos.
Atención al CEO: señalar con los dedos 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.
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 cambio, recomiendo probar unidades de "unidades de funcionalidad" reales. 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.
Te recomiendo que evites 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.
Un beneficio 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.
La mejor manera es no llegar a ser tan técnico con personas "no técnicas". 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.
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 con las pruebas en mente, 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.
Tu no 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.
Una buena forma de vender el valor de las pruebas unitarias es desde el punto de vista del soporte: si está utilizando un marco de prueba unitario que tiene un tiempo de ejecución que puede implementarse (nUnit es uno), puede tener un elemento de menú "Ejecutar pruebas de unidad" 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.
Vender pruebas unitarias completas después de que el desarrollo ya haya 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 la prueba completa de la unidad por adelantado, entonces debería estar contento con cualquier prueba unitaria que pueda ingresar.
Intenta 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 choque)