pruebas - ¿Es excesivo ejecutar la prueba unitaria con Valgrind?
pruebas unitarias (2)
Hace unos días comencé a buscar en un marco de prueba unitario llamado verificación, y tengo la intención de ejecutar la prueba en el código c en Linux.
Ahora revise y algún código bien diseñado y algún código de prueba pueden ayudarme a verificar que la funcionalidad básica es correcta, quiero decir que es bastante fácil simplemente mirar las variables y la respuesta y luego decidir si una función es correcta o no.
Pero digamos que quiero probar una estructura de memoria dinámica con mucho malloc y libre, y resulta que puedo poner datos y volver a obtener los datos correctos. Pero eso no prueba que no haya roto algo de memoria en el proceso, digamos que olvidé liberar la mitad de la memoria y perdí los punteros (un Memleak clásico). Ese código probablemente pase la mayor parte de las pruebas unitarias.
Entonces, ahora, para la pregunta: ¿es una buena idea ejecutar todo el código de prueba de la unidad con, por ejemplo, Valgrind y dejar que detecte problemas malloc / free? (¿O compilar algo como Electric Fence?)
Se siente como una buena idea, pero no estoy seguro de en qué me estoy metiendo aquí .....
Gracias Johan
Actualización: Gracias Douglas y Jonathan, parece que esta es una buena idea y algo con lo que debería continuar :-)
Actualización: Valgrind es una herramienta divertida, sin embargo, las primeras memleaks que encontré haciendo esto fueron en el marco de prueba y no en mi propio código (aunque bastante gracioso). Así que un consejo para el resto es verificar que el marco de prueba de la unidad que está utilizando no esté goteando, antes de dar vuelta su propio código al revés. Un caso de prueba vacío era todo lo que se necesitaba en mi caso, desde entonces no se está ejecutando nada más que el marco de prueba de la unidad.
Como dijo Douglas Leeder, vale la pena ejecutar las pruebas de su unidad con cualquier software de diagnóstico que pueda poner en sus manos para garantizar que realmente funcione como espera. Eso incluye no abusar de la memoria, por lo que usar valgrind es una buena idea.
Realmente quieres que las pruebas de tu unidad demuestren que tu código funciona.
No tiene que ejecutarlos bajo valgrind todo el tiempo, pero debe ser lo más trivial posible, y debe hacerlo periódicamente (por ejemplo, después de grandes cambios).
Ciertamente lo hacemos - es mucho más fácil ejecutar valgrind contra las pruebas unitarias que con el programa completo.
Además, cualquier error de memoria se localiza en el área de código que la prueba unitaria está probando, lo que hace que sea más fácil de arreglar.
Además, es más fácil verificar que lo haya solucionado, porque está ejecutando la prueba unitaria, que no es una prueba más complicada para su programa completo.
Si está ejecutando valgrind de manera automatizada, probablemente desee --error-exitcode=<number> [default: 0]
Especifica un código de salida alternativo para devolver si Valgrind informó algún error en la ejecución. Cuando se establece en el valor predeterminado (cero), el valor de retorno de Valgrind siempre será el valor de retorno del proceso que se simula. Cuando se establece en un valor distinto de cero, ese valor se devuelve en su lugar, si Valgrind detecta algún error. Esto es útil para usar Valgrind como parte de un conjunto de pruebas automatizadas, ya que facilita la detección de casos de prueba para los cuales Valgrind ha informado errores, simplemente mediante la inspección de códigos de retorno.
http://valgrind.org/docs/manual/manual-core.html#manual-core.erropts