NMock2.0 - comment stub un appel d'interface non?

Question

J'ai une API de classe qui a une couverture complète de code et utilise DI pour se moquer de toutes les logiques de la fonction principale de la classe (Job.Run) qui fait tout le travail.

J'ai trouvé un bug dans la production où nous ne savions faire une validation sur l'un des champs de saisie de données.

Alors, j'ai ajouté une fonction de talon appelé ValidateFoo () ... A écrit le test unitaire avec cette fonction Attendez-vous JobFailedException, a couru le test - il n'a pas de toute évidence parce que la fonction était vide. J'ai ajouté la logique de validation, et maintenant le test passe.

Grand, maintenant, nous savons que la validation fonctionne. Le problème est - comment puis-je écrire le test pour vous assurer que ValidateFoo () est en fait appelé à l'intérieur Job.Run ()? ValidateFoo () est une méthode privée de la classe d'emploi - il est donc pas une interface ...

Y at-il de toute façon de le faire avec NMock2.0? Je sais que Typemock soutient fakes de types d'interface non. Mais le changement libs simulacres est actuellement pas une option. A ce stade, si NMock ne peut pas supporter, je vais tout simplement ajouter le ValidateFoo () pour la course () méthode et les choses tester manuellement - méthode qui, évidemment, je préfère ne pas faire mon compte Job.Run () a 100% de couverture en ce moment. Aucun conseil? Merci beaucoup il est apprécié.

EDIT: l'autre option que j'ai à l'esprit est de créer simplement un test d'intégration pour ma fonctionnalité Job.Run (injection de véritables implémentations il des objets composites au lieu de se moque). Je vais lui donner une valeur d'entrée mauvaise pour ce champ, puis vérifier que le travail a échoué. Cela fonctionne et couvre mon test - mais pas vraiment un test unitaire, mais plutôt un test d'intégration qui teste une unité de fonctionnalité .... hmm ..

EDIT2: Est-il possible de le faire tihs? Quelqu'un at-il des idées? Peut-être Typemock - ou une meilleure conception

Answer 1

La version actuelle de NMock2 peut se moquer de types concrets (je ne me souviens pas exactement quelle version ils ajouté, mais nous utilisons la version 2.1) en utilisant la syntaxe familière pour la plupart:

Job job = mockery.NewMock<Job>(MockStyle.Transparent);
Stub.On(job).Method("ValidateFoo").Will(Return.Value(true));

MockStyle.Transparent spécifie que tout ce que vous ne cognez pas ou attendez devraient être traitées par la mise en œuvre sous-jacente -. Vous pouvez donc stub et définir les attentes pour les méthodes sur une instance que vous testez

Cependant, vous ne pouvez stub et définir les attentes sur les méthodes publiques (et propriétés), qui doit aussi être virtuelle ou abstraite. Donc, pour éviter de se fier sur les tests d'intégration, vous avez deux options:

• public Job.ValidateFoo() et virtuel.
• Extraire la logique de validation dans une nouvelle classe et injecter une instance dans Job.

Answer 2

Comme toutes privées sont toutes appelées par les méthodes publiques (à moins compter sur l'exécution d'exécution de réflexion), alors ces soldats sont en cours d'exécution par des méthodes publiques. Ces méthodes privées sont à l'origine des modifications à l'objet au-delà du code simple d'exécution, tels que la configuration des champs de classe ou d'appeler à d'autres objets. Je trouverais un moyen d'obtenir à ces « résultats » d'appeler la méthode privée. (En se moquant des choses qui ne doivent pas être exécutées dans les méthodes privées.)

Je ne vois pas la classe en cours de test. Un autre problème qui pourrait être vous pousser à vouloir accéder aux méthodes privées est que c'est une super classe grande avec un bateau plein de fonctionnalités privées. Ces classes peuvent devoir être répartis en classes plus petites, et certains de ces soldats peuvent se transformer en des publics plus simples.