Pregunta

Estoy tratando de escribir una prueba de la unidad C # con el marco de pruebas de VS 2008 incorporado en la unidad y el método que estoy probando llamadas Environment.Exit(0). Cuando llamo a este método en mi prueba de unidad, mi unidad de prueba se aborta. El método debe ser hecho llamando Exit, y quiero una manera de probar que lo hace, y también para poner a prueba el código de salida que utiliza. ¿Cómo puede hacer esto? Miré a Microsoft.VisualStudio.TestTools.UnitTesting espacio de nombres , pero no vio nada que se pareciera relevante.

[TestMethod]
[DeploymentItem("myprog.exe")]
public void MyProgTest()
{
    // Want to ensure this Exit's with code 0:
    MyProg_Accessor.myMethod();
}

Mientras tanto, aquí está la esencia del código que quiero prueba:

static void myMethod()
{
    Environment.Exit(0);
}

Editar esta es la solución que he usado en mi método de prueba, gracias a RichardOD :

Process proc;

try
{
    proc = Process.Start(path, myArgs);
}
catch (System.ComponentModel.Win32Exception ex)
{
    proc = null;
    Assert.Fail(ex.Message);
}

Assert.IsNotNull(proc);
proc.WaitForExit(10000);
Assert.IsTrue(proc.HasExited);
Assert.AreEqual(code, proc.ExitCode);
¿Fue útil?

Solución

Esto suena como una muy mala idea. Environment.Exit (0), obviamente hará según lo prescrito, por lo tanto, por qué sus testeos unitarios están rompiendo.

Si realmente quieres probar esto todavía sea posible mediante el lanzamiento de un proceso separado y comprobar el retorno de código- echar un vistazo a envolverlo en Process.Start .

Creo que otra opción es el factoring el código y la inyección de un espía prueba , o el uso de un objeto de burla para verificar el comportamiento correcto.

Tal vez se puede hacer algo con Typemock Isolator- Creo que esto le permite métodos estáticos simulacros .

Otros consejos

Usted tendrá que crear un contenedor para la clase de Medio Ambiente, a continuación, utilizar el contenedor en el código. Para las pruebas unitarias, inyectar una versión simulada de la envoltura. En el siguiente ejemplo se utiliza RhinoMocks para verificar que el método llama a la envoltura con el argumento esperado.

public class EnvironmentWrapper
{
    public virtual void Exit( int code )
    {
        Environment.Exit( code );
    }
}


public class MyClass
{
    private EnvironmentWrapper Environment { get; set; }

    public MyClass() : this( null ) { }

    public MyClass( EnvironmentWrapper wrapper )
    {
        this.Environment = wrapper ?? new EnvironmentWrapper();
    }

    public void MyMethod( int code )
    {
        this.Environment.Exit( code )
    }
}


[TestMethod]
public void MyMethodTest()
{
     var mockWrapper = MockRepository.GenerateMock<EnvironmentWrapper>();

     int expectedCode = 5;

     mockWrapper.Expect( m => m.Exit( expectedCode ) );

     var myClass = new MyClass( mockWrapper );

     myclass.MyMethod( expectedCode );

     mockWrapper.VerifyAllExpectations()
}

Usted no será capaz de probar esto - Environment.Exit mata a la aplicación por completo. Esto significa que cualquier dominio de aplicación que utiliza este código será descargado por completo, si se trata de la aplicación de producción o en el marco de la unidad de pruebas.

Su única opción en este caso sería burlarse de la clase del Medio Ambiente con un método fakie salida.

Puede añadir un argumento a su método de pasarlo de un entorno falso donde el método exit () no se cerrará.

Puede este método parametrizada extraído del método llamado desde la aplicación, y la unidad de probar la función extraído. De esta manera, usted no tendrá que modificar su aplicación.

La única cosa que viene a la mente es algo a lo largo:

static void myMethod()
{
    DoEnvironmentExit(0);
}

static void DoEnvironentExit(int code)
{
    #if defined TEST_SOLUTION
      SomeMockingFunction(code);
    #else
      Environment.Exit(code);
    #endif
}
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top