Test unità VS2008 - metodo assertivo uscite

Question

Sto provando a scrivere un test dell'unità C# con il framework di test unità integrato di VS 2008 e il metodo che sto testando chiama Environment.Exit(0). Quando chiamo questo metodo nel mio test unitario, il mio test unitario viene interrotto. Il metodo dovrebbe infatti chiamare Exit, e voglio un modo per testarlo, e anche per testare il codice di uscita che usa. Come potrei farlo? Ho guardato allo Microsoft.VisualStudio.TestTools.UnitTesting Namespace ma non ho visto nulla di rilevante.

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

Nel frattempo, qui è l'essenza del codice che voglio prova:

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

Edit: ecco la soluzione che ho usato nel mio metodo di prova, grazie 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); 

Answer 1

Sembra un'idea davvero pessima. Environment.Exit (0), ovviamente farà come prescritto, quindi perché i test unitari si stanno rompendo.

Se si vuole ancora testare questo, è possibile avviare un processo separato e controllare il codice di ritorno, dare uno sguardo al pacchetto in Process.Start.

Suppongo che un'altra opzione sia il factoring di questo codice e l'iniezione di un test spy o l'utilizzo di un oggetto fittizio per verificare il comportamento corretto.

Forse si può fare qualcosa con Typemock Isolator- Credo che questo ti permetta di mock static methods.

Answer 2

Non è possibile testare questo - Environment.Exit uccide completamente l'applicazione. Ciò significa che qualsiasi AppDomain che utilizza questo codice verrà scaricato completamente, indipendentemente dal fatto che si tratti dell'applicazione di produzione o del framework di test delle unità.

Answer 3

L'unica opzione qui sarebbe di prendere in giro la classe Ambiente con un metodo di uscita di fakie.

Answer 4

È necessario creare un wrapper per la classe Environment, quindi utilizzare il wrapper nel codice. Per i tuoi test unitari, inserisci una versione finta del wrapper. L'esempio seguente utilizza RhinoMocks per verificare che il metodo chiami il wrapper con l'argomento previsto.

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 5

È possibile aggiungere un argomento per il metodo di passare un ambiente falso in cui il metodo exit() non lo faranno uscire.

Questo metodo parametrico può essere estratto dal metodo richiamato dall'applicazione e l'unità verifica la funzione estratta. In questo modo, non dovrai modificare la tua app.

Answer 6

L'unica cosa che mi viene in mente è qualcosa insieme:

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

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