var contextChannel = this.MockRepository.Stub<IContextChannel>(); var context = this.MockRepository.Stub<IOperationContext>(); context.Stub(x => x.Channel).Return(contextChannel); context.Replay(); What is Replay for?I understand that in the case of recording and then playing back an action, the Replay() call is necessary. But it is unclear to me why I am forced to write one more line of code in the case where I do not record anything. All I need is a property which returns my object.
3 Réponses :
Avant que la méthode Replay est appelée Les moqueurs Rhinomocks se trouve dans l'état d'enregistrement. Cela signifie que vous pouvez contrôler comment le simulacteur se comportera, même si vous n'êtes pas recordnignigner quoi que ce soit en soi, vous racontez toujours le moquer comment se comporter isomg par exemple La méthode enregistrement n'existe que pour permettre aux tests de ramener un objet de maquette à l'état d'enregistrement et de modifier le comportement du simulateur. Je recommanderais fortement à ce sujet. En règle générale, je viens d'utiliser le Stub . Calling Replay Arrête votre test de la modification de la façon dont la maquette se comporte et commence à se comporter comme si vous avez inséré.
mockrepository.replayallall () et mockrepository.verifytall () méthodes.
Pourriez-vous s'il vous plaît élargir votre réponse avec une autre ma question: alors pourquoi la fonction mockRepository.record () existe du tout si l'enregistrement est activé par défaut?
Je pense qu'il est raisonnable de mettre l'objet dans l'état d'enregistrement lorsque .EXPECT () ou des fonctions similaires sont utilisés. Cependant, je ne vois aucune raison de mettre de l'objet dans l'état d'enregistrement lorsque simple .stub (). Retour () Les choses sont utilisées.
Vasiliy: Vous avez raison: il n'y a pas besoin de rejouer. Pas même pour attendre. Jetez un coup d'œil à ma réponse mise à jour.
Vous n'utilisez pas correctement la syntaxe AAA. Vous n'avez plus besoin d'une instance sur le mockèpository (ceci avait été utilisé pour Rhino avant 3.5). Appelez simplement les méthodes statiques sur MockRepository: P> vous ne le faites pas. Il n'est pas nécessaire d'appeler dans les versions précédentes, il y avait un paradigme "record-reclise", où vous avez enregistré des attentes et les rejoué pendant le test. Il avait été remplacé par la syntaxe AAA, où vous pourrez beaucoup plus facilement et plus flexible, installez des simulacres. P> Dans les coulisses, il y a toujours un état d'enregistrement et de replay de la maquette. Les méthodes telles que Si vous souhaitez effectuer des opérations plus avancées, vous pouvez définir vous-même l'état de Replay vous-même, faire quelque chose avec il, par exemple. Afin de réinitialiser les attentes: p> mock.BackToRecord(BackToRecordOptions.All);
mock.Replay();
replay code> dans une situation comme la vôtre plus. P> Stub code> mettent la maquette dans l'état d'enregistrement, le configurent et les remettent enregistrement. Vous n'avez pas besoin d'appeler enregistrement code> explicitement dans ces cas. P>
Malheureusement sans la relecture () appeler mon test échoue avec le message suivant: 'ioperationContext.get_channel ();' Nécessite une valeur de retour ou une exception à jeter. (J'ai les derniers moqueurs de Rhino 3.6.) Donc, «pas besoin d'appeler Replay» n'est pas vrai dans votre réponse.
Ce doit être un autre problème. Il n'est pas nécessaire d'appeler la relecture après le talon.
C'est la réponse que je cherchais. Merci beaucoup pour votre temps et vos efforts. Enfin, j'ai clairement de nos tests pour moi et à des collègues.
var stubbedInterface = MockRepository.GenerateStub<IAnInterface>(); stubbedInterface.Stub(x =>SomeProperty).Return(someValue);
Merci pour la séparation. Bien que c'est une technologie très ancienne et inutilisée. Donc, je ne me suis même pas dérangé.