Si je teste un wrapper de service, devrais-je abstraire tout?

Question

J'ai une classe de service de service utilisé pour résumer mes appels de mon projet MVC à mon service de repos. Tout ce que la classe Manager est configuré les appels de repos (à l'aide de RESTSHARP) et renvoie les données de service à l'application MVC.

Donc, au début, je pensais à ne pas tester une telle classe triviale, mais j'ai décidé que les tests permettront de protéger contre des changements futurs pouvant être plus complexes.

Cependant, voici mon dilemme. Jusqu'où devrais-je abstraire des choses pour que je puisse tester isolément?

Donc, je suis en train d'être injecté par MVC dans la classe de mon manager. Je laisse l'injecteur MVC fixer l'URL de base. Tout cela, je vais bien, mais voici les questions que j'ai:

• Pour mon appel de méthode, dois-je avoir ma méthode prise dans un paramètre (ID utilisateur) et un IRESTREQUEST?
  • Mon problème avec c'est que tout d'un coup, mon servicanager générique deviendra SPECT spécifique car mon interface devra inclure les deux paramètres.
  • Si je n'injecte pas l'IRESTREQUEST dans la méthode et que vous laissez la mise en œuvre la créer, est-ce correct, car cela sera ignoré car la méthode principale étant testée est la restclient.execute, qui sera plongée et ne se soucie pas de la RestRequest actuel?
    • En fait, comme cela fait partie de la mise en œuvre, je pouvais peut-être se moquer et vérifier que la méthode d'exécution est envoyée dans l'objet RestRequest approprié?
    • ou, devrais-je ne pas injecter l'irrégularité, mais injecter un euxilestresolver dans mon constructeur? Ensuite, dans mon méthodalcall, je peux simplement utiliser l'iRequestressolver, qui prendra dans une chaîne représentant la méthode. Cela servira ensuite à comprendre les paramètres de resquète et à renvoyer un objet RestRequest rempli de manière appropriée pour la méthode?
    • ou, devrais-je simplement effectuer essentiellement la sous-balle sous ma première balle et utiliser la mise en œuvre concrète.
    • Toutes autres options que je manques?

      Je suis appuyé vers la quatrième balle car il se fait sur la solution actuelle?

      Faites-moi savoir si vous avez besoin de plus de détails pour m'aider à résoudre mon dilemme.

Answer 1

Après avoir discuté avec un ami, j'ai décidé d'utiliser la mise en œuvre concrète.

La raison étant que cet objet est vraiment juste un poco, et il n'est pas nécessaire de résumer cela (même si une abstraction est fournie).Ceci est ma mise en œuvre concrète de mon appelant de service. La solution actuelle étant testée est l'appel.Je vais probablement se moquer de cela et vérifier que le restant est appelé comme ça devrait être, cependant.

Mais, la réponse courte que nous avons proposée est que le Poco n'a pas besoin d'être résumé.

Answer 2

Je connais bien ce dilemme; et ont été ici plusieurs fois.

Quand cela revient, vous pouvez abstraire tout, mais vous vous retrouvez avec des tests sans signification et vous constatez que vous écrivez le cadre de test qui n'a pas d'importance ou que vous ne contournez pas les normes de cadre acceptées à la recherche de la «une vraie méthodologie de test». J'ai réellement été dans des conversations où les gens ont discuté honnêtement débattant des interfaces abstraites qui ont juste besoin de mettre un entier.

Alors que vous écrivez cela, j'ai vu votre propre réponse; et je suis complètement d'accord.

Tant que vous pouvez valider les hypothèses et le comportement des tests, alors vous en faites assez; Comme vous dites - vous n'avez besoin que de vérifier que les choses ont changé et vous connaissez vous-même les frontières de votre propre contexte - le fournisseur changera-t-il de manière réaliste? Non - ne résumez pas ça.

Récemment, j'ai généré des solutions de CRM Microsoft Dynamics à grande échelle pour mon employeur; En fin de compte, mes tests supposent que l'API CRM est correcte et il suffit de tester le comportement de mes emballages.

Quoi qu'il en soit, c'est juste le ballpark comme je le vois, j'espère que cela est de votre valeur pour vous!