Pruebas unitarias: cómo hacerlo?

Question

Quiero probar la unidad de mi programa (en C) porque sé de los beneficios de hacerlo también, ya que muestra dónde está el problema.

También me gusta la caja negra de prueba, ya que me dice que si el programa funciona (al menos, para las pruebas).

Por el momento, estoy usando autotest (que viene con Autoconf) con el fin de no agregar una dependencia.

En este punto, no me importaría mucho usar un mejor marco de trabajo, pero el problema es que no quiero utilizar un marco diferente para blackbox y pruebas unitarias. ¿Sería posible ejecutar las pruebas de blackbox desde un marco de prueba de unidad? Lo que realmente me gustaría es una buena salida de registro, diciendo exactamente qué salió mal y dónde.

Mi otra opción es prueba de la unidad con autotest. El problema es que no hay marco. He escrito un pequeño "controlador de prueba" que acepta el nombre de la función para probar y los argumentos para pasar a la función y llama a esa función. El problema es que no estoy seguro de qué límite usar entre las aserciones y generar el valor de retorno de la función (para fines de registro, ya que me gusta cómo Autotest me proporcionará una diferencia). Como la mayoría de las funciones devuelven listas, es más rápido prepararse usando el diff con la salida esperada (expout usando Autotest).

Answer 1

¿Sería posible ejecutar las pruebas de caja negra de un marco prueba de unidad?

Sí, puede invocar el Autotest con system() desde las pruebas unitarias y luego afirmar en el valor devuelto.

Pero no recomendaría hacerlo ya que las pruebas unitarias se ejecutan con mucha frecuencia, serán muy rápidas, es decir, medidas en segundos, no en minutos.

Las pruebas unitarias y pruebas de integración (que se llama a las pruebas de caja negra) tienen finalidades diferentes: las pruebas unitarias validan que los unidades en el código (lo que esto significa, función o grupos de función) funciona como se espera por las pruebas, mientras las pruebas de integración cubren el programa de principio a fin y lo validan como un todo.

Por lo tanto, normalmente las pruebas unitarias se ejecutan después de cada pocos cambios en el código, especialmente si aplica TDD, mientras que las pruebas de integración se ejecutan cuando se agrega una capacidad.

Preferiría tener un programa (s) de prueba unitaria típico, con aserciones, y un conjunto de integración que invocara las pruebas unitarias además de las pruebas de blackbox.

El problema es que no estoy seguro de qué límites a utilizar entre las afirmaciones y dar salida al valor de retorno de la función (para fines de registro, ya que me gusta cómo autotest me dará un diff).

Con afirmaciones no hay nada a la salida: los valores, ya sea el esperado y el real son iguales y no pasa nada, o son diferentes y las impresiones marco UT fuera un mensaje de error (que se espera es X, real es Y). Esa es una de dejar que la computadora haga el trabajo de probar.

Con la salida de registro diff, todavía hay que inspeccionar manualmente (visualmente) el resultado del diff (por ejemplo: ¿falta un elemento en la lista o un elemento adicional ...).

Dado que la mayoría de las funciones devuelven listas, es más rápido preparar usando el diff con la salida esperada (expout usando Autotest).

Es posible que desee escribir una función que compare listas utilizando aserciones.

Answer 2

Es posible que desee utilizar CTest, que viene con CMake, un sistema de construcción de plataforma cruzada con muchos backends: http://www.cmake.org/Wiki/CMake#CTest

PS: CMake es mucho más potente que autotools también.