2010-12-15 19 views
6

Sólo necesito a prueba unitaria algunos métodos como éste:Subprocesos de prueba de la unidad?

public void start() 
{ 
    myThread.Start(); 
} 

public void stop() 
{ 
    myThread.Abort(); 
} 

¿Cómo puedo hacer eso? Puedo llamar al método de inicio y verificar si IsAlive == verdadero, pero luego el hilo sigue trabajando en segundo plano y llama a su propio método. Otra forma es que llamo a inicio y luego me detengo de inmediato, pero no es claro porque sería como si estuviera probando dos cosas. ¡Es tan simple pero arghh!

Respuesta

0

¿Por qué necesita de probar la unidad esos métodos? ¿Qué estás tratando de verificar? ¿Se romperán otras pruebas si lo que intentas verificar no es cierto? (Es decir, ¿está cubierto por otras pruebas?)

Si no, puede entrar en semáforos, y hacer que su unidad de prueba se asegure de que el hilo se inicie antes de un tiempo de espera determinado, pero simplemente no creo que sea extremadamente valioso prueba al final. No aumentaría mucho mi confianza.

2

Es una buena idea hacer que las cosas que dependen del tiempo sean síncronas para los fines de las pruebas. (De hecho, es una buena idea localizar interacciones dependientes del tiempo incluso en el uso sin pruebas.)

Si realmente quiere comprobar que estos métodos inician y detienen un hilo, insertaría un objeto ficticio myThread que proporciona esos métodos, pero en realidad no inicia un hilo, o un hilo cuyo código simplemente se quedará y esperará sin hacer nada. Luego puede registrar que se inició y se detuvo, sin preocuparse por la complejidad de lo que su hilo real hará.

Tal vez su situación es más compleja que simplemente comprobar que se inició el hilo? Puede ser útil si publica un ejemplo un poco más grande del tipo de cosas que desea probar.

1

Estoy de acuerdo con BnWasteland en que, para el ejemplo de código dado, lo único que se puede probar es que System.Threading.Thread.Start y System.Threading.Thread.Abort funcionen correctamente. Por lo tanto, sería razonable suponer que lo son y enfocarse en el propio código de la Aplicación. Luego tiene dos dominios:

1) El código de la tarea real que se ejecuta dentro de la secuencia. Esto se puede probar en una prueba de unidad normal.

2) Asegúrese de que la infraestructura multiproceso funcione como se espera.

(2) tiende más a la categoría de pruebas de integración, pero nadie prohíbe el uso de la estructura Unit-tesitng para esto. Y en este caso está bien hacer Start/Stop e incluso hacer esto varias veces con algunas cargas de trabajo aleatorias solo para asegurarnos de que el sistema se comporta y hace el trabajo. Obviamente, esto entra en una demanda de prueba de "larga duración" que no es necesario que desee ejecutar en cada check-in.

6

El truco consiste en separar el comportamiento asincrónico de su lógica. Observe que su lógica real es síncrona y que la parte asíncrona es simplemente un "tiempo de espera" intermedio.

El libro xUnit Test Patterns lo describe bien. Incluso es un patrón: Humble Object. Se explica mucho mejor que yo.