Moq - Checking-Methode aufrufen, auf der konkreten Klasse

Hier ist ein sehr einfaches Beispiel, was ich versuche zu tun:

public class Bar
{
    public void SomeMethod(string param)
    {
        //whatever
    }
}

public interface IBarRepository
{
    List<Bar> GetBarsFromStore();
}

public class FooService
{
    private readonly IBarRepository _barRepository;

    public FooService(IBarRepository barRepository)
    {
        _barRepository = barRepository;
    }

    public List<Bar> GetBars()
    {
        var bars = _barRepository.GetBarsFromStore();
        foreach (var bar in bars)
        {
            bar.SomeMethod("someValue");
        }
        return bars;
    }
}

In meinem test, ich bin mocking IBarRepository Rückkehr eine konkrete Liste definiert in der unit-Tests und übergabe verspottet repository-Instanz an die FooService Konstruktor.

Möchte ich überprüfen, in der FooService Methode GetBars, dass SomeMethod was called für jede der Bars zurück aus dem repository. Ich bin mit Moq. Gibt es eine Möglichkeit, dies zu tun, ohne Spott die Liste der Bars zurück (wenn noch möglich) und nicht, dass einige hacky-flag in Bar (igitt) ?.

Ich bin folgenden ein Beispiel aus einem DDD-Buch, aber ich fange an zu denken, es riecht, da bin ich herausgefordert, den Test der Implementierung....

InformationsquelleAutor drogon | 2012-02-02

c#moq nunit unit-testing

Überarbeitet... das geht vorbei:

public class Bar
{
    public virtual void SomeMethod(string param)
    {
        //whatever
    }
}

public interface IBarRepository
{
    List<Bar> GetBarsFromStore();
}

public class FooService
{
    private readonly IBarRepository _barRepository;

    public FooService(IBarRepository barRepository)
    {
        _barRepository = barRepository;
    }

    public List<Bar> GetBars()
    {
        var bars = _barRepository.GetBarsFromStore();
        foreach (var bar in bars)
        {
            bar.SomeMethod("someValue");
        }
        return bars;
    }
}

[TestMethod]
public void Verify_All_Bars_Called()
{
    var myBarStub = new Mock<Bar>();
    var mySecondBarStub = new Mock<Bar>();

    var myBarList = new List<Bar>() { myBarStub.Object, mySecondBarStub.Object };
    var myStub = new Mock<IBarRepository>();
    myStub.Setup(repos => repos.GetBarsFromStore()).Returns(myBarList);
    var myService = new FooService(myStub.Object);
    myService.GetBars();

    myBarStub.Verify(bar => bar.SomeMethod(It.IsAny<string>()), Times.Once());
    mySecondBarStub.Verify(bar => bar.SomeMethod(It.IsAny<string>()), Times.Once());
}

Beachten Sie die geringfügige änderung, Klasse Bar (SomeMethod() ist virtuell). Eine Veränderung, aber nicht mit einem flag... 🙂

Nun, in Bezug auf eine breitere design, gibt es einige Mutationen gehen mit Ihrem bar (was auch immer "SomeMethod()" eigentlich nicht). Das beste, was zu tun wäre wahrscheinlich stellen Sie sicher, dass diese mutation passiert auf jeder Bar zurück aus FooService.GetBars(). Das heißt, richten Sie Ihr repository stub wieder einige bars, und stellen Sie dann sicher, dass alles, was mutation erfolgt durch SomeMethod() stattgefunden hat. Nachdem alle, die Sie Steuern, die Bars, die zurückgegeben werden, so dass Sie einrichten können Ihre pre-SomeMethod () - Zustand, und überprüfen Sie dann Ihre post-SomeMethod() Zustand.

Danke! Ich war nur in den Prozess der Spott der Bars. Ich bin froh, dass Sie tun können, dass mit Moq.
Freut mich wenn es geholfen hat. Und ja, Sie können mock alle virtuellen Methoden/Eigenschaften der konkreten Klasse, solange die konkrete Klasse muss einen parameterlosen Konstruktor hat (wenn es nicht, Moq werfen Ausnahmen)

InformationsquelleAutor Erik Dietrich

2

Wenn ich schreiben diese Klassen durch unit-Tests im Hinterkopf, würde ich wahrscheinlich entweder die Klasse Bar implementieren eine Schnittstelle IBar und verwenden Sie die Schnittstelle in meinem Dienst, oder machen SomeMethod virtuelle Bar.

Idealerweise so:
```
public interface IBar
{
    void SomeMethod(string param);
}

public class Bar : IBar
{
    public void SomeMethod(string param) {}
}

public interface IBarRepository
{
    List<IBar> GetBarsFromStore();
}

public class FooService
{
    private readonly IBarRepository _barRepository;

    public FooService(IBarRepository barRepository)
    {
        _barRepository = barRepository;
    }

    public List<IBar> GetBars()
    {
        var bars = _barRepository.GetBarsFromStore();
        foreach (var bar in bars)
        {
            bar.SomeMethod("someValue");
        }
        return bars;
    }
}
```
Dann meine unit-test würde wie folgt Aussehen:
```
[Test]
public void TestSomeMethodCalledForEachBar()
{
    //Setup
    var barMocks = new Mock<IBar>[] { new Mock<IBar>(), new Mock<IBar>() };
    var barObjects = barMocks.Select(m => m.Object);
    var repoList = new List<IBar>(barsObjects);
    var repositoryMock = new Mock<IBarRepository>();
    repositoryMock.Setup(r => r.GetBarsFromStore()).Returns(repoList);

    //Execute
    var service = new FooService(repositoryMock.Object);
    service.GetBars();

    //Assert
    foreach(var barMock in barMocks)
        barMock.Verify(b => b.SomeMethod("someValue"));
}
```
- Hinzufügen Schnittstelle nur für tests ist nicht gut meiner Meinung nach. Dies führt zu Unsinn "ifoo") vom, IFooImpl. Nur stellen Sie virtuelle Methode.
- Ich würde nicht sagen, es war irgendein problem mit Schnittstellen benannt, wie Ihre Beispiele. Ich würde sagen, Sie sind es für einen Grund geben ein Abstraktions-layer zwischen Vertragsabschluss und Durchführung). Indem Sie die virtuelle Methode, wenn ich wollte, ändern Sie die Implementierung von DoSomething() ich hätte Ableitung von Bar (ist jetzt möglich), wahrscheinlich gewinnt eine Menge von Mitgliedern, die ich möchte nicht. Durch die Kodierung einer Schnittstelle würde ich nur umsetzen müssen, was erforderlich war, eine Reduzierung der Komplexität und nachher macht es einfacher, mit zu arbeiten.
- "Ifoo") vom, IFooImpl ist ein code, den Geruch für mich. Wenn es IAmSomeAbstraction und Klasse ConcreteExampleOfThatAbstraction dann ist es ok. Mit Impl postfix einen Namen macht keinen Sinn. Natürlich ist es die Umsetzung.
- Check hier auf der msdn, beachten Sie Folgendes: weiß sicher, dass bei der Definition einer Klasse/Schnittstelle koppeln, wo die Klasse ist eine standard-Implementierung des interfaces, die Namen unterscheiden sich nur durch den Buchstaben I-Präfix auf den Namen der Schnittstelle. ich denke, der kann viel von microsoft Praktiken, die code, die Sie verwenden, was Sie als ein "Code Smell'. Aber wir müssen Zustimmen, disagre 🙂
- Und wo sehen Sie hierbei Impl postfix vorgeschlagen? Also sagen wir mal ich habe eine Art von Benachrichtigungen in meiner software. Standard-Benachrichtigung per E-Mail. Sie (und msdn) empfehlen die Erstellung IEmailNotifier und eine Klasse EmailNotifier? Ich kann nicht glauben, schlimmer. Diese sind nicht Abstrakt, Abstraktionen'. Das sollte INotification-und Standard-Klasse wäre EmailNotifier. Weitere Diskussion Aussehen hier und die übrigen Beiträge in dieser Serie.
- Ich würde erstellen Sie eine Schnittstelle INotifier und vielleicht eine default-Implementierung von Notifier, aber es wäre eine Implementierung von INotifier genannt EmailNotifier. Ich fürchte, ich bin verloren, was meinst du Impl postfix. Für die askers Frage, ich sagte lediglich ich würde Ihnen einige-Schnittstelle IBar, IFoo, was auch immer es ist, nur entsprechend benanntes und mit den Bar würde, es umzusetzen. Es ist nur ein Beispiel, vielleicht wäre es übersichtlicher gewesen, wenn ich verwendet hatte IFoo, aber es scheint, bilden Sie eine Frage über dummy-Namen.
- Ich wusste nicht, aber Sie meinte eigentlich das erstellen von Schnittstellen mit der postfix-impl? Yeh, ich würde das nicht tun und bin nicht sicher, warum würden Sie am Ende zu tun. Eine Schnittstelle namens IFoo wäre perfekt für mich durchaus akzeptabel, wenn es zur Verfügung gestellt Foo Funktionalität.
- Was würde das Standard-Notifier tun? EmailNotifier ist ok. Ich Sprach über "ifoo") vom, FooImpl Paare. Sie sind code-Duft für mich.
- lassen Sie uns weiter, diese Diskussion im chat
InformationsquelleAutor Lukazoid

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.