Supongo que mi proyecto se desacopla lo suficiente como para permitir la prueba de la unidad. ¿Pero qué tan grande, exactamente, en términos de clases y funciones tiene que ser mi proyecto para que las pruebas unitarias valgan la pena?
Todos cometemos errores y nadie es perfecto, pero me considero un programador decente para manejar los errores de pequeños proyectos con el paso. ¿O es la prueba de unidad una necesidad difícil sin importar el tamaño de su proyecto?
En mi experiencia, una una clase y una una función han sido suficientes para considerar la necesidad de pruebas de unidad.
class Simple {
boolean reallySimple() {
return true; // how do we make sure it doesn't change to false?
}
}
class SimpleTest {
void assertReallySimple() {
// ensure reallySimple return value isn't changed unexpectedly
UnitTestFramework.assertTrue(new Simple().reallySimple());
}
}
Nunca he comprado la idea de "debes probar todo de una unidad", aunque ciertamente hay personas que lo tienen (consulta la respuesta del mosquito !).
En lo que a mí respecta, los principales beneficios de las pruebas unitarias son:
Básicamente, debe sopesar el tiempo que le tomará escribir & mantener pruebas contra estos factores.
El número 1 suele ser suficiente para que valga la pena escribir exámenes. En mi experiencia, > el 95% del código se modifica tarde o temprano.
Es simple: no necesitas pruebas de unidad si descartas el programa después de ejecutarlo una vez.
Si esto te parece excesivo, considera lo que significaría la alternativa. Si hubiera un tamaño por debajo del cual las pruebas de unidad no pagan, tendrías que seguir pensando en tu mente: "¿Ya alcancé el tamaño mágico? ¿Debo comenzar a escribir pruebas?" Ahora, los programadores son notoriamente malos para predecir el futuro, y son notoriamente malos para juzgar su propia habilidad. El código que se ve muy claro para usted ahora será incomprensible, incluso para usted, incluso al esperar un mes. Un proyecto en el que está absolutamente seguro de que nunca volverá a ser utilizado, y que se limita a la remota posibilidad de que desee consultar cómo resolvió algo antes, será solicitado nuevamente, y recibirá solicitudes de cambio.
Por lo tanto, es muy probable que juzgues mal si las pruebas son útiles o no, y cuando comienzas a necesitarlas, ya no estás 100% seguro de cuál es la semántica exacta que se debe probar. Dado que creo que todos, excepto los programas únicos triviales, se benefician de las pruebas unitarias, considero que el costo de gastar esfuerzos en las pruebas que nunca se ejecutan nuevamente es insignificante contra los riesgos de extender el código no probado y mal entendido.
Hace algún tiempo encontré una buena publicación: Por qué las pruebas unitarias aceleran el desarrollo . Puede ayudarte a responder la pregunta.
... ¿Qué pasa si el código base ... se proporcionó con un conjunto sustancial de pruebas unitarias? Un conjunto que diría: "si todas las pruebas tienen éxito, garantizo que el código todavía hace lo que debería hacer" y si una prueba falla, muestra exactamente dónde se rompe algún comportamiento. Esto es genial, podría cambiar el código para agregar las cosas que quiero sin deambular si el código todavía hace lo que debería hacer, simplemente hago las ... pruebas y tengo fe. Este es un gran mundo como ingeniero de software. Me di cuenta de que podía avanzar mucho más rápido ...
Tengo "fe".
Esta es probablemente la razón más importante por la que las pruebas unitarias aceleran el desarrollo en un contexto empresarial.
Puedo confiar en que todo seguirá funcionando si todas las pruebas pasan. Si las pruebas fallan, señalarán exactamente dónde se encuentra el problema ...
... tienes que tener una alta cobertura de pruebas unitarias y buenas pruebas unitarias . Cuando se respeten estas condiciones, se encontrará en una situación en la que el esfuerzo por agregar nuevas funcionalidades es casi independiente del tamaño de la aplicación y que, a la larga, acelerará el desarrollo .
Michael Feathers presentó en uno de sus libros dos formas de trabajar con cambios en el código:
No importa qué tan grande sea el código base.
Según Kent Beck en su respuesta a la pregunta de desbordamiento de pila ¿Qué tan profundas son sus pruebas de unidad? , debe probar el código que tiende a equivocarse.
Si normalmente no cometo un tipo de error (como establecer las variables incorrectas en un constructor), no lo pruebo.
Las pruebas unitarias se implementan para ahorrar tiempo y mejorar:
Es obligatorio escribir pruebas unitarias para partes relativamente complejas del programa.
Si está seguro de que escribir pruebas de unidad ahora no ahorrará su tiempo en el futuro, puede omitirlo. Sin embargo, nunca se sabe, y personalmente no puedo pensar en un caso en el que sea más barato (en el sentido del tiempo, el dinero y los nervios) no escribir pruebas de unidad, sino realizar todas las pruebas manualmente.
A menos que escriba un código sin probarlo, siempre incurrirá en el costo de la prueba.
La diferencia entre tener pruebas unitarias y no tenerlas es la diferencia entre el costo de escribir la prueba y el costo de ejecutarla en comparación con el costo de la prueba a mano.
Si el costo de escribir una prueba unitaria es de 2 minutos y el costo de la ejecución de la prueba unitaria es prácticamente 0, pero el costo de la prueba manual del código es de 1 minuto, entonces usted gana el equilibrio cuando ha ejecutado la prueba dos veces.
Durante muchos años tuve la mala interpretación de que no tenía tiempo suficiente para escribir pruebas unitarias para mi código. Cuando escribí las pruebas, estaban hinchadas, cosas pesadas que solo me animaban a pensar que solo debería escribir pruebas de unidad cuando sabía que eran necesarias.
Recientemente me animaron a usar Development Driven Development y me pareció una revelación completa. Ahora estoy firmemente convencido de que no tengo el tiempo not para escribir pruebas unitarias.
En mi experiencia, al desarrollar teniendo en cuenta las pruebas, terminas con interfaces más limpias, clases más centradas y amp; módulos y en general más SOLID , código verificable.
Cada vez que trabajo con un código heredado que no tiene pruebas de unidad y tengo que probar algo manualmente, sigo pensando que "esto sería mucho más rápido si este código ya tuviera pruebas de unidad". Cada vez que tengo que intentar agregar una funcionalidad de prueba unitaria a un código con alto acoplamiento, sigo pensando que "esto sería mucho más fácil si se hubiera escrito de una manera desacoplada".
TL; DR versión:
Escriba una prueba cuando el costo de escribir la prueba, más el costo de realizarla tantas veces como sea necesario, probablemente sea menor que el costo de realizar la prueba manualmente tantas veces como sea necesario.
Sin embargo, recuerde que si usa TDD, es probable que el costo de escribir las pruebas disminuya a medida que mejore, y a menos que el código sea absolutamente trivial, probablemente terminará ejecutando las pruebas con más frecuencia de la que espera.
Realice la prueba tan pronto como observe que ocurren regresiones o que tenga miedo de causar algunas con sus ediciones y sin darse cuenta.
Encienda ese miedo, déjelo crecer a un tamaño adecuado: cuanto antes realice la prueba, mejor.
Tenga en cuenta: dependiendo de su rol en el proyecto, es posible que las pruebas unitarias no sean el único tipo de pruebas que desee escribir.
Todo el mundo está legítimamente obsesionado con las pruebas unitarias , debido a las malas prácticas de pruebas en el pasado; pero si nunca lo probaste antes, deberías centrarte en probar en general , las pruebas unitarias por sí solas no van a resolver los problemas del mundo.
"¿Debería probar esto en una unidad?" generalmente se puede responder respondiendo a la siguiente pregunta: "¿Es importante que esta función funcione correctamente y es importante para mí saber cuándo deja de funcionar?"
Por supuesto, es mucho más complicado que eso, pero es una buena manera de comenzar. Finalmente, también pesará si el código ya se está probando debido a que se está utilizando en otra función, o si su tiempo sería mejor empleado en otra función, etc.
Creo que no es el tamaño del proyecto, sino el tipo de proyecto que decide si debería usar las pruebas o no.
Si está trabajando en una prueba de concepto, o en algún otro proyecto donde el objetivo es aprender de la codificación, no se requieren pruebas. Si el proyecto está destinado a ser utilizado, incluso puede ser enviado a producción, entonces debe ser probado.
Una cita de "Clean Code" de Robert C. Martin : "Si es trivial escribir, es trivial para probar ", así que no hay excusa para omitir las pruebas para programas cortos y triviales.
Realmente no es una cuestión de tamaño, es lo que haces con él (y su antigüedad). Si no estoy aprendiendo cómo funciona una tecnología y planeo tirar la cosa (llamamos a esto un pico en Scrum), solo codificaré sin hacer muchas pruebas. Si planea desarrollarlo aún más (incluso si solo está haciendo fideos), debe escribir pruebas alrededor del código. TDD es una técnica de diseño incluso antes de ser una técnica de prueba. Desea tener una idea clara de lo que quiere que haga el código antes de vincularse con los detalles de la ejecución. También recomendaría NO intentar escribir pruebas de unidad exhaustivas en torno a grandes cantidades de código heredado. Intente identificar aquellas partes que son complejas (que tienen un alto grado de complejidad ciclomática / sensación de código de espagueti) y aquellas partes que fallan con frecuencia (a menudo serán las mismas). Como otros han sugerido, iría a leer el libro de Kent Beck en TDD y definitivamente leería el libro de Michael Feather. Lo que no cubren mucho es el aspecto político para escribir pruebas unitarias en torno al código. Muchos desarrolladores odian tener que alterar su código para hacerlo comprobable, y muchos desarrolladores no sienten la necesidad de probar el código en absoluto. Es algo en lo que tenemos que trabajar como profesión. Se requiere que cualquier otra disciplina de ingeniería pruebe (a menudo matemáticamente) que su trabajo cumplió con la especificación. Deberíamos hacer lo mismo.
Vincular un proyecto en límites de clases o funcionalidad y luego determinar si esto es adecuado para la prueba de unidad puede ser incorrecto. La prueba de una aplicación tiene numerosos beneficios, pero la belleza real comienza cuando tienes que mantener una aplicación o tienes que trabajar en un entorno distribuido. Así que la elección viene aquí. Incluso un pequeño cambio en su código puede causar desastres.
No solo sugeriría 'Pruebas de unidad' sino que también recomendaría verificar la cobertura de su código, asegurando que el máximo de su código esté cubierto con la Prueba de unidad. El umbral para la cobertura del código no debe ser inferior a 95% y el objetivo debe estar alrededor de 100% . Puede buscar herramientas para rastrear la cobertura de su código y generar un informe.
Visual Studio proporciona datos de cobertura, enlace
También puedes usar NCover o dotCover.
Lea otras preguntas en las etiquetas unit-testing error-handling project-management programming-practices