VS2008 Unit-Tests - assert Methode Exits

Question

Ich teste Anrufe Environment.Exit(0)

Ich versuche, einen C # Unit-Test mit VS 2008 eingebauten in Unit-Test-Framework und das Verfahren zu schreiben. Wenn ich diese Methode in meiner Unit-Test aufrufen, wird meine Einheit Test abgebrochen. Das Verfahren sollte in der Tat sein Exit anrufen, und ich möchte eine Art und Weise zu testen, ob es funktioniert, und auch den Exit-Code zu testen, die es verwendet. Wie könnte ich das tun? Ich schaute auf Microsoft.VisualStudio.TestTools.UnitTesting Namespace , aber nicht sehen, etwas, das aussah, relevant.

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

Inzwischen, hier ist der Kern des Code, den ich testen will:

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

Edit: hier ist die Lösung, die ich in meiner Test-Methode verwendet, dank 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);

Answer 1

Das klingt wie eine unglaublich schlechte Idee. Environment.Exit (0), wird offensichtlich nicht, wie vorgeschrieben, warum also Ihr Gerät testings brechen.

Wenn Sie wirklich wollen, noch dies testen Sie können durch einen separaten Prozess starten und die Rückkehr Überprüfung Code- einen Blick auf das Einwickeln in Process.Start .

Ich denke, eine weitere Option, diesen Code aus Factoring und ein Test Spion Injektion oder mit ein Mock-Objekt korrektes Verhalten zu überprüfen.

Vielleicht können Sie etwas mit Typemock Isolator- tun Ich glaube, das können Sie a href = " Mock statische Methoden .

Answer 2

Sie müssen einen Wrapper für Umwelt-Klasse erstellen, dann die Verpackung in Ihrem Code verwenden. Für Ihre Unit-Tests, eine Mock-Version des Wrapper injiziert. Das folgende Beispiel verwendet RhinoMocks um sicherzustellen, dass das Verfahren den Wrapper mit dem erwarteten Argumente aufruft.

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()
}

Answer 3

Sie werden nicht in der Lage sein, diese zu testen - Environment.Exit tötet die vollständig Anwendung. Dies bedeutet, dass jede AppDomain, die diesen Code verwendet wird vollständig entladen werden, ob es Ihre Produktion Anwendung ist oder das Gerät Test-Framework.

Answer 4

Ihre einzige Option wäre hier die Umweltklasse mit einer fakie Exit-Methode zu verspotten.

Answer 5

Sie können ein Argument zu Ihrer Methode hinzufügen, um ihm eine gefälschte Umgebung zu passieren, wo der Ausfahrt () -Methode wird nicht verlassen.

Sie können diese parametrisierte Methode aus der aus Ihrer Anwendung aufgerufen Verfahren extrahiert und Einheit testen Sie die extrahierten Funktion. Auf diese Weise werden Sie nicht Ihre app ändern.

Answer 6

Das einzige, was mir in den Sinn kommt, ist etwas zusammen:

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

static void DoEnvironentExit(int code)
{
    #if defined TEST_SOLUTION
      SomeMockingFunction(code);
    #else
      Environment.Exit(code);
    #endif
}