Unidad probando una aplicación basada en temporizador?

Question

Actualmente estoy escribiendo una mini aplicación simple basada en temporizador en C# que realiza una acción n veces cada k segundos.
Estoy tratando de adoptar un estilo de desarrollo basado en pruebas, por lo que mi objetivo es probar todas las partes de la aplicación.

Entonces, mi pregunta es: ¿hay una buena manera de probar la unidad de una clase basada en temporizador?

El problema, como yo lo veo, es que hay un gran riesgo de que las pruebas se llevarán a incómodamente tiempo para ejecutarse, ya que tienen que esperar tanto y tanto tiempo para que las acciones deseadas sucedan.
Especialmente si uno quiere datos realistas (segundos), en lugar de utilizar la resolución de tiempo mínima permitida por el marco (1 ms?).
Estoy usando un objeto de simulacro para la acción, para registrar el número de veces que se llamó a la acción, y para que la acción no tome prácticamente ningún tiempo.

Answer 1

Lo que he hecho es burlar el temporizador, y también la hora actual del sistema, que mis eventos podrían activarse inmediatamente, pero en lo que respecta al código bajo prueba, el tiempo transcurrido fue de segundos.

Answer 2

Creo que lo que haría en este caso es probar el código que realmente se ejecuta cuando el temporizador marca, en lugar de la secuencia completa. Lo que realmente necesita decidir es si vale la pena que pruebe el comportamiento real de la aplicación (por ejemplo, si lo que sucede después de cada marca cambia drásticamente de una marca a otra), o si es suficiente (es decir , la acción es la misma siempre) para probar tu lógica.

Dado que el comportamiento del temporizador está garantizado y nunca cambiará, o bien va a funcionar correctamente (es decir, lo ha configurado correctamente) o no; parece ser un esfuerzo desperdiciado incluir eso en su prueba si realmente no lo necesita.

Answer 3

tiene una serie de 20 articles on testing timer based code.

Answer 4

Estoy de acuerdo con Danny en la medida en que probablemente tenga sentido desde el punto de vista de la unidad de evaluación simplemente olvidarse del mecanismo del temporizador y simplemente verificar que la acción en sí funciona como se esperaba. También diría que no estoy de acuerdo en que es un esfuerzo inútil incluir la configuración del temporizador en un conjunto de pruebas automatizadas de algún tipo. Hay muchos casos límite cuando se trata de trabajar con aplicaciones de tiempo y es muy fácil crear una falsa sensación de seguridad al probar solo las cosas que son fáciles de probar.

Recomendaría tener un conjunto de pruebas que ejecute el temporizador, así como la acción real. Esta suite probablemente demorará un tiempo en ejecutarse y probablemente no sea algo que ejecute todo el tiempo en su máquina local. Pero establecer este tipo de cosas en una compilación automática nocturna puede ayudar a eliminar los errores antes de que sean demasiado difíciles de encontrar y corregir.

Así que, en resumen, mi respuesta a su pregunta es: no se preocupe por escribir algunas pruebas que tardan mucho tiempo en ejecutarse. Pruebe con una unidad lo que pueda y haga que el conjunto de pruebas se ejecute rápido y con frecuencia, pero asegúrese de complementarlo con pruebas de integración que se ejecutan con menos frecuencia pero que cubren más aplicaciones y su configuración.