Tests unitaires VS2008 - sortie de la méthode assert

Question

J'essaie d'écrire un test unitaire C# avec le cadre de test unitaire intégré de VS 2008 et la méthode que je teste les appels Environment.Exit(0). Lorsque j'appelle cette méthode dans mon test unitaire, mon test d'unité est Aborted. La méthode devrait en effet appeler Exit, et je veux un moyen de tester ce qu'il fait, et aussi de tester le code de sortie qu'il utilise. Comment pourrais-je faire ça? J'ai regardé Microsoft.VisualStudio.TestTools.UnitTesting Namespace mais je n'ai rien vu de pertinent.

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

En attendant, voici l'essentiel du code que je veux tester:

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

Edit: est la solution ici je dans ma méthode d'essai, grâce à 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

Cela semble être une très mauvaise idée. Environment.Exit (0), va évidemment faire comme prescrit, d'où la raison pour laquelle vos tests unitaires se brisent.

Si vous voulez vraiment continuer à tester cela, vous pouvez lancer un processus séparé et vérifier le code de retour - jetez un coup d'œil pour l'encapsuler dans Process.Start.

Je suppose qu'une autre option est de factoriser ce code et d'injecter un test spy, ou en utilisant un objet simulé pour vérifier le comportement correct.

Peut-être que vous pouvez faire quelque chose avec Typemock Isolator - Je crois que cela vous permet de mock static methods.

Answer 2

Vous ne serez pas en mesure de tester cela - Environment.Exit tue complètement l'application. Cela signifie que tout AppDomain qui utilise ce code sera complètement déchargé, que ce soit votre application de production ou le framework de test unitaire.

Answer 3

Votre seule option ici serait de simuler la classe d'environnement avec une méthode de sortie fakie.

Answer 4

Vous devrez créer un wrapper pour la classe Environment, puis utiliser le wrapper dans votre code. Pour vos tests unitaires, injectez une version fictive du wrapper. L'exemple suivant utilise RhinoMocks pour vérifier que la méthode appelle le wrapper avec l'argument attendu.

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

Vous pouvez ajouter un argument à votre méthode pour lui transmettre un faux environnement dans lequel la méthode exit() ne se fermera pas.

Vous pouvez extraire cette méthode paramétrée de la méthode appelée depuis votre application et tester la fonction extraite. De cette façon, vous n'aurez pas à modifier votre application.

Answer 6

La seule chose qui me vient à l'esprit est quelque chose le long:

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

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