2009-07-29 6 views
24

mon équipe a pris la décision récemment d'utiliser Moq comme notre cadre moqueur pour sa grande flexibilité et sa syntaxe très lisible. Comme nous sommes nouveaux, je trébuche sur ce qui semble être des questions simples - les recherches (ici, Google, etc.) trouvent beaucoup de discussions sur d'autres nuances de Moq, mais pas nécessairement ce que je suis après, et les quelques questions apparemment apparentées se sont transformées en harengs rouges.Les méthodes d'annulation de court-circuit avec Moq?

Nous testons une classe qui a une dépendance externe (Amazon SimpleDb pour être précis) mais ne veut pas que nos tests soient liés à une connexion live. Une méthode particulière:

  • applique une « entreprise » logique
  • Le cas échéant, invoque un appel vers SDB via un fournisseur que nous avons construit, nous allons l'appeler SaveItem()

Je veux à l'unité tester ceci de telle sorte que nous configurons le contexte requis et nous assurons que SaveItem() a été invoqué, mais d'une manière que SaveItem() n'est pas vraiment invoquée (parce que A) le fournisseur de SDB est un simulacre qui n'est pas complètement hydraté et bombardera probablement B) Je ne veux pas avoir à payer pour cette transaction des centaines et des milliers de fois).

En traitant des méthodes qui ont renvoyé une valeur, c'était trivial.

mockDb.Setup(d => d.GiveMeSomething()).Returns("Foo"); 

Dans le cas où je décris ci-dessus si, mon « SaveItem() » méthode est vide et donc la possibilité d'utiliser la méthode Returns() de Moq n'est pas disponible. Et bien que je puisse configurer un rappel pour vérifier SaveItem() est invoqué, je ne peux pas cependant sembler l'obtenir à ne rien faire réellement.

Naive/espoir, je pensais que ce qui suit fonctionnerait, mais il semble encore invoquer la méthode:

mockDb.Setup(d => d.SaveItem(It.IsAny<object>())); 

La question de millions de dollars: Quel est le Moq du code fictif suivant?

mockDb.Setup(d => d.SaveItem(It.IsAny<object>())).STOP_RIGHT_HERE(); 
+0

Modifié pour clarifier la situation, le test est pour une classe « affaires » flottant autour, non pas pour la mise en œuvre réelle SimpleDB. L'implémentation SimpleDB est testée ailleurs, ici, c'est ce que je me moque. – bakasan

Répondre

29

Si la méthode SaveItem() est virtuelle ou abstraite, et vous n'êtes pas mise Callbase = true, la méthode devrait être mis en œuvre à nouveau de ne rien faire par la maquette.

Vous devriez être en mesure de le faire:

mockDb.Setup(d => d.SaveItem(It.IsAny<object>())).Verifiable(); 

... test here ... 

mockDb.Verify(); 
+0

Parfait! Absolument aucune idée que c'était l'intention de la vérification Verifiable()/Verify(), et sans documentation plus formelle, n'aurait même pas connu de lire sur les discussions et les messages dans cette zone. Je viens de faire un tourbillon et j'ai maintenant des cas de tests positifs et négatifs contre ce scénario. Merci beaucoup! – bakasan

+2

+1; En outre, vous pouvez également vérifier tous vos appels quel que soit l'indicateur Vérifiable() en appelant mockDb.VerifyAll() –

+0

Possible pour que cette réponse soit développée pour l'autre scénario i.e méthode n'est ni virtuelle ni abstraite? – leon

Questions connexes