2017-06-27 9 views
0

Ich versuche, Moq zu verwenden, um Elemente zu einem Repository zu simulieren und dann die Anzahl der Elemente zu überprüfen, aber es gibt mir immer 0 Elemente, etwas ist falsch in meinem Code, können Sie Bitte hilf mir?Moq Repository gibt 0 Elemente zurück

var candidate = new Candidate { Id = Guid.NewGuid()};    
var repo = new Mock<ICandidateRepository<Candidate>>(); 
repo.Setup(x => x.Insert(candidate)); 
repo.Setup(x => x.Submit()); 

candidateBL.setRepository(repo.Object); 
MinifiedCount<MinifiedCandidate> result = candidateBL.Get(username, skip, take, id); 

Innerhalb candidateBL Ich habe die Repository-Variable überprüft und hat 0 Elemente.

Vielen Dank.

+0

Was ist 'candidateBL'? Können Sie den Code der 'candidateBL.Get' Methode teilen? –

+0

es ist zu lang und nicht wirklich helfen, das Problem zu beheben, ich habe die Zeile, wo ich das Repository festgelegt und es gibt mir 5 Elemente, aber ich möchte ein Mock Repository verwenden ... Vielen Dank @ChetanRanpariya – TiagoM

+0

Ich hoffe, Sie erwarte nicht die 'Insert' und' Submit' Aufrufe, um 'candidate' irgendwo in ein Repository zu stellen ... –

Antwort

2

Ohne mehr von Ihrem Code zu sehen, bin ich ziemlich zuversichtlich, dass Sie in die Falle geraten sind zu denken, dass ein Spott einer Schnittstelle irgendwie Logik in Bezug auf Ihre Implementierung dieser Schnittstelle hat.

Mit anderen Worten, es sieht aus wie denken Sie, dass dieser Code candidate tatsächlich in das Repository einfügen wird:

repo.Setup(x => x.Insert(candidate)); 
repo.Setup(x => x.Submit()); 

Wenn das Ihr Verständnis ist, , die bei allen nicht der Fall ist. Der Code oben sagt Ihren Mock erwarten einen Anruf an Insert mit der angegebenen Candidate Instanz, und auch einen Anruf an Submit zu erwarten. Die Methoden eines verspotteten Objekts haben keine Implementierung; Sie tun genau das, was Sie ihnen von den Setup Methoden zu tun gesagt haben.

Anstatt den Mock wie eine tatsächliche Implementierung zu behandeln, müssen Sie ihm sagen, wie reagieren, wenn von Ihrem Code im Test verwendet wird. Zum Beispiel, sagen wir mal, dass Ihr candidateBL.Get Methode etwas Einfaches wie das ist:

public Candidate Get(Guid id) 
{ 
    try 
    { 
     return _repository.Find(id); 
    } 
    catch (KeyNotFoundException) 
    { 
     return null; 
    } 
} 

Nun stell dir vor du bist diese Methode zu testen. Im einfachen Fall gibt es hier zwei Testfälle: einer, bei dem eine einzige Candidate im Repository gefunden und zurückgegeben wird, und eine andere, wo das Repository auslöst, wenn die id nicht existiert. Sie müssen den Mock so einrichten, dass diese Fälle in jedem Test berücksichtigt werden.

Der erste Test würde das Repository Mock setzen sich wie folgt zusammen:

var repo = new Mock<ICandidateRepository<Candidate>>(); 
repo.Setup(x => x.Find(candidate.Id)).Returns(candidate)); 

Beachten Sie, dass keine wo habe ich den Kandidaten einfügen; Stattdessen sagte ich dem Spötter, er solle es mir zurückgeben, wenn ich Find mit einer spezifischen Kennung anrufe.

Und der Vollständigkeit halber, würde der zweite Test es bis zu werfen:

var repo = new Mock<ICandidateRepository<Candidate>>(); 
repo.Setup(x => x.Find(candidate.Id)).Throws(new KeyNotFoundException())); 
+0

Hallo @PatrickQuirk meine Get-Methode ist riesig, es eine Auswahl am Start und dann die Elemente mit Where-Ausdrücke (linq).Kann ich meine Get-Methode nicht selbst testen? – TiagoM

+0

Hey @PatrickQuirk Ich bemerke, dass diese Tests davon ausgehen, dass candidate.Id bereits auf dem Repository richtig existiert? Ich möchte ein sauberes Repository erstellen und die Elemente dort einfügen, dann Get-Methode mit allen optionalen Argumenten testen, damit ich alle Elemente im Repository erhalte – TiagoM

Verwandte Themen