Comment écrire stub méthode avec NUnit en C#

J'ai 2 classes:

  • FirstDeep.cs
  • SecondDeep.cs

    J'ai fait simple code pour l'exemple:


class FirstDeep
    {
        public FirstDeep() { }

        public string AddA(string str)
        {
            SecondDeep sd = new SecondDeep();
            bool flag = sd.SomethingToDo(str);

            if (flag == true)
                str = string.Concat(str, "AAA");
            else
                str = string.Concat(str, "BBB");

            return str;
        }
    }

et

class SecondDeep
    {
        public bool SomethingToDo(string str)
        {
            bool flag = false;
            if (str.Length < 10)
            {
                //todo something in DB, and after that flag should be TRUE
            }
            return flag;
        }
    }

Alors je veux écrire unité de test pour la méthode "AddA":

class Tests
    {
        [Test]
        public void AddATest()
        {
            string expected = "ABCAAA";

            FirstDeep fd = new FirstDeep();
            string res = fd.AddA("ABC");

            Assert.AreEqual(expected, res);
        }
    }

Et après que j'ai de la difficulté, je ne sais pas comment corriger écrire stub pour la méthode SomethingToDo dans ma classe de Test. J'ai toujours faux. Je dois retourner la valeur TRUE. Mais comment?

vous pouvez toujours travailler avec votre modèle: introduire bool expected = false; SecondDeep sd = new SecondDeep(); bool actualResult = sd.SomethingToDo("ABC"); Assert.AreEqual(excpected, actualResult); ...!? si ce n'est pas meed à vos besoins, vous devriez probablement envisager d'élaborer et d'améliorer votre question!
Avez-vous réglé votre code? Si ça se passe dans la base de données, nous ne pouvons pas vous aider car nous n'avons pas de détails de ce qui s'y passe.
Oui, j'ai réglé mon code, et où j'ai écrit: "//todo quelque chose dans la DB, et après que le drapeau doit être VRAI", j'ai l'aide de la classe MembershipUser .NET et cette méthode ne peut pas se connecter à la DB, c'est pourquoi j'ai juste retour de vrai sur cette affaire.

OriginalL'auteur Smit | 2012-05-08

  1. 11

    Un bon moyen de vous permettre d'écrire des talons est d'utiliser l'injection de dépendance. FirstDeep dépend SecondDeep et dans votre test, vous voulez remplacer SecondDeep avec un talon de.

    Premier changement de votre code existant par l'extraction d'une interface pour SecondDeep et puis à l'injecter dans FirstDeep dans le constructeur:

    interface ISecondDeep {

  Boolean SomethingToDo(String str);

}

class SecondDeep : ISecondDeep { ... }

class FirstDeep {

  readonly ISecondDeep secondDeep;

  public FirstDeep(ISecondDeep secondDeep) {
    this.secondDeep = secondDeep;
  }

  public String AddA(String str) {   
    var flag = this.secondDeep.SomethingToDo(str);
    ...
  }

}

    Noter que FirstDeep ne crée plus une SecondDeep instance. Plutôt qu'une instance est injecté dans le constructeur.

    Dans votre test, vous pouvez créer un stub pour ISecondDeep où SomethingToDo renvoie toujours vrai:

    class SecondDeepStub : ISecondDeep {

  public Boolean SomethingToDo(String str) {
    return true;
  }

}

    Dans le test, vous utilisez la stub:

    var firstDeep = new FirstDeep(new SecondDeepStub());

    Dans la production de code que vous utilisez le "vrai" SecondDeep:

    var firstDeep = new FirstDeep(new SecondDeep());

    À l'aide d'un conteneur d'injection de dépendances et d'un stubbing cadre peut faire beaucoup de choses à faire.

    Si vous ne voulez pas de réécrire votre code, vous pouvez utiliser un cadre pour l'interception des appels, comme Microsoft Taupes. Dans la prochaine version de Visual Studio une technologie similaire sera disponible dans la Faux Cadre.

    OriginalL'auteur Martin Liversage

  2. 4

    Afin de rendre votre code testable, ne pas instancier les dépendances à l'intérieur de votre classe. Utilisation l'injection de dépendance (via le constructeur, de propriété ou d'un paramètre). Aussi l'utilisation de classes abstraites et interfaces pour permettre aux moqueries des dépendances:

    class FirstDeep
{
    private ISecondDeep oa;

    public FirstDeep(ISecondDeep oa) 
    { 
        this.oa = oa;
    }

    public string AddA(string str)
    {
       return String.Concat(str, oa.SomethingToDo(str) ? "AAA" : "BBB");
    }
}

    Selon les abstractions vous permet de tester votre classe dans l'isolement. 

    interface ISecondDeep
{
   bool SomethingToDo(string str);
}

class SecondDeep : ISecondDeep
{
    public bool SomethingToDo(string str)
    {
       bool flag = false;
       if (str.Length < 10)
       {
           //without abstraction your test will require database
       }
       return flag;
    }
}

    Ici est le test de l'échantillon (à l'aide de Moq). Il vous montre comment vous pouvez retourner true à partir de l'appel à votre moqué de la dépendance:

    [TestFixture]
class Tests
{
    [Test]
    public void AddAAATest()
    {
        //Arrange
        Mock<ISecondDeep> secondDeep = new Mock<ISecondDeep>();
        secondDeep.Setup(x => x.SomethingToDo(It.IsAny<string>())).Returns(true);
        //Act
        FirstDeep fd = new FirstDeep(secondDeep.Object);
        //Assert
        Assert.That(fd.AddA("ABD"), Is.EqualTo("ABCAAA"));
     }
}

    OriginalL'auteur Sergey Berezovskiy