2011-05-11 35 views
20

Esta pregunta simplemente me vino a la mente y quiero preguntar esto aquí.¿Cómo se prueba un método que se ejecuta en un bucle infinito para alguna entrada?

El caso es intencional, simplemente escribo un ciclo que se ejecuta infinitamente. ¿Cómo hago para probar la unidad?

Lo pregunto porque, esta situación puede ocurrir en cualquier parte del código. Dicen mis delegados método para varios otros métodos, y quieren saber

  • Cómo se corrió en un bucle infinito
  • Qué conjunto de entrada causó
  • Llamada a qué método (de este método) ha causado

No tengo código escrito para esto. La pregunta es solo por el conocimiento en cuanto a qué hacer si esta situación se presenta en el futuro. Por favor responde.

+1

¿El ciclo infinito es intencional? Además, Google "detiene el problema". – dlev

+0

¿Puedo saber el motivo por el que se ha cerrado esta pregunta y por qué cerrarla? – Shankar

+0

@dlev, sí, es intencional. Esto me vino a la mente cuando estaba pensando en una situación en la que esto podría suceder – Shankar

Respuesta

11

Cómo probar un método que se ejecuta en un bucle infinito para algunas entradas?

Puede probar la casi enfrente: "¿Cómo unidad de prueba de un método para que el método no funcionará durante más tiempo de lo milisegundos Xxxx por alguna entrada". Si esta prueba falla, es posible que haya encontrado un candidato con un ciclo infinito.

NUnit 2.5 tiene un TimeoutAttribute que hace que una prueba falle si la prueba lleva más tiempo que la cantidad dada de milisegundos.

7

Espero que se refiera a algún tipo de ciclo de bombeo de mensajes/manejo de eventos. (La mayoría de los bucles infinitos son malos).

Me aseguraré de que el bucle delegue en alguna clase que procese la entrada. Prueba esta clase a fondo.

La probabilidad de que una construcción de bucle no funcione es mínima ... Así que probaría esto a través de una prueba de aceptación o manualmente.

Esto es algo similar a probar la función principal de un ejecutable. El truco aquí también es asegurar que Main delegue en una clase verificable.

3

El propósito de la unidad es probar cada unidad más simple en su programa.

La unidad más simple es generalmente una función que cumple una única misión, por lo que para unir tu Loop infinito tendrás que extraer cada misión que este Loop podría hacer en una función separada que se puede llamar sola, una vez hecho esto usted podrá llamar a estas funciones, les dará todos los parámetros posibles para probar diferentes szenarios que su función debería poder manejar. El bucle infinito como función no tiene que estar unificado, sino las misiones más pequeñas dentro de él.

7

Tenga la función que los bucles delegar el control de bucle a una dependencia inyectada:

interface IShouldLoop 
{ 
    bool ShouldLoop(); 
} 

class ClassToTest 
{ 
    private final IShouldLoop shouldLoop; 

    public ClassToTest(IShouldLoop shouldLoop) 
    { 
     this.shouldLoop = shouldLoop; 
    } 

    public void MethodToTest() 
    { 
     while(shouldLoop.ShouldLoop()) 
     { 
      // do whatever 
     } 
    } 
} 

Se puede probar que delega la verificación de bucle a la dependencia IShouldLoop cada vez, y se puede controlar el bucle en su prueba , de modo que solo se repita el número de veces que desee. En el entorno de producción, instanciarlo con una instancia de IShouldLoop que siempre devuelve verdadero.

+0

+1. Muy buen enfoque. –

+0

Me gusta este enfoque. Creo que los nombres 'LoopCondition' y' isTrue() 'tienen más sentido. – byxor

+0

Otra opción es marcar el método como virtual y anularlo para probarlo – Mohsen

Cuestiones relacionadas