2010-12-21 9 views
8

Estoy desarrollando una aplicación que maneja CTRL-C. Estoy produciendo un manejador de señal para cerrar con gracia los hilos y otros recursos.pruebas de unidad para CTRL-C enviadas a una aplicación

Quiero probar CTRL-C en diferentes escenarios donde podría estar mi aplicación. Sé cómo configurarlos para el proceso bajo prueba, pero necesito una forma (en el código del conjunto de pruebas en funcionamiento) para verificar si se alcanza esa condición o no para llamar exactamente a CTRL-C.

Trabajo en Linux y quiero ejecutar mis pruebas automáticamente con la ayuda de CPPUNIT. En cada una de mis pruebas CTRL-C comienzo el proceso y luego envío CTRL-C usando la función kill que tiene el PID del proceso.

Estoy utilizando la memoria compartida; una vez que la aplicación probada alcanza una condición de mi interés o un punto en el que me gustaría enviar CTRL-C, escribo una etiqueta o un estado en la memoria compartida. Al mismo tiempo, el código del conjunto de pruebas que se ejecuta en un proceso diferente está sondeando continuamente la memoria compartida y, una vez que lee el estado deseado, envía CTRL-C/kill.

¿Crees que es un buen enfoque o generalmente se hace de maneras mejores/efectivas?

Saludos cordiales

AFG

+0

posible duplicado de [¿Por qué no puedo causar un fallo de seg?] (Http://stackoverflow.com/questions/2045314/why-cant-i-cause-a-seg-fault) –

Respuesta

5

Primera probar el comportamiento cuando se recibe alguna señal externa no se parece a la unidad de pruebas pero al igual que las pruebas funcionales.

Además, la forma en que lo haces también suena demasiado complicado y es probable que fuerce algún tipo de sincronización y oculte algunos comportamientos.

Por otro lado, realmente no tengo algo mejor que sugerir para este tipo de pruebas, esto generalmente se hace con herramientas externas de una manera mucho menos controlada.

+0

Veo A qué te refieres. Alguna clase de "DEMASIADO COMPLICADO" también codifica. ¿Qué tipo de herramienta quieres decir? ¿Son estas fuentes gratuitas/abiertas? –

+0

+1 los controladores de señal de prueba también me parecen pruebas funcionales. –

+0

+1, de hecho es para una prueba funcional - no para una prueba de unidad –

2

Introduce un nivel de indirección.

  1. Coloque su código de programa de alto nivel detrás de una fachada (utilizo una clase llamada Program).
  2. Hagan que Facade proporcione un método shutdown(), que realiza toda la operación de apagado, excepto llamar a std::exit().
  3. La unidad prueba ese método shutdown() como lo haría con cualquier otro método.
  4. Hacer que el delegado de controlador de señal para que shutdown() método para el objeto staticProgram que representa todo el programa a continuación call std::exit(). Esta es la única parte que no puedes probar unitario.
+0

Hola y gracias. Ya hago algo muy similar. Mi función main() básicamente crea una instancia de lo que es para usted la clase 'Programa'. Si lo uso dentro de mi prueba de unidad y configuro un manejador de señal para el 'Programa; clase, luego voy a configurar un controlador de señal también para el corredor de prueba y me gustaría evitar eso y tratar de tener como el caso real, es decir, un proceso separado donde puedo llamar desde el exterior matar. De todos modos, trataré de cavar mejor la idea de un apagado estático(). Para esto tengo que revisar el manejo de la señal. Son requisitos muy estrictos. –

+0

Si sigo su enfoque, debo asegurarme de restaurar el controlador de señal original durante setUp()/tearDown() del banco de pruebas. Creo que valdría la pena intentarlo. –

+1

Puede dividir los requisitos de prueba en dos: si la recepción de un SIGTERM causa un apagado controlado, y realiza un apagado controlado correctamente, libera recursos, cierra archivos, etc. Las pruebas de unidad pueden ayudarlo con el segundo, probando su método shutdown() pero no es adecuado para el primero. – Raedwald

Cuestiones relacionadas