Confus sur les wrappers/adaptateurs TDD

Question

Je suis nouveau sur la scène TDD et essayer d'isoler mes tests me fait tourner en rond.

J'ai une application que j'essaie d'écrire qui utilise OpenXML afin qu'il ait une masse d'objets dont il dépend pour travailler à partir d'un framework externe. Je pensais que ce serait une bonne idée d'avoir des wrappers autour de ces objets afin d'en être isolé en cas de changements etc. Mon problème est que pour représenter quelque chose comme une cellule, je passe dans une vraie cellule dans mon wrapper (donc il a quelque chose à emballer) dans le constructeur.

Pour tester cette enveloppe, je dois passer dans une vraie cellule de l'infrastructure OpenXML. Ok c'est faisable mais je voulais aussi passer une SharedStringTablePart au constructeur afin qu'il puisse stocker la valeur de la chaîne (si c'était une chaîne partagée) pour une récupération facile. SharedStringTablePart possède un constructeur protégé de sorte que vous ne pouvez pas en créer un à la volée dans un test pour tester.

Sooo, je crée un emballage pour cela aussi, mais comment puis-je tester ce nouvel emballage? Je ne peux pas passer une SharedStringTablePart via une injection de dépendance car je ne peux pas en créer une.

Je dois parler à l'interface de la 3ème partie à un moment donné dans mon architecture d'application, n'est-ce pas, et tester cette couche? Est-ce que je crée simplement des wrappers et que je ne m'occupe pas de la partie TDD et que je suppose qu'ils fonctionneront si je passe par les mêmes requêtes et réponds avec les mêmes réponses que l'objet encapsulé attendrait/ferait?

Non que cela fait une différence à ce niveau mais je suis en utilisant C#

grâce Nev

Answer 1

C'est le problème avec le code d'intégration, il ne correspond pas à l'essai des puits de l'unité. Ci-dessus ne signifie pas que vous devez laisser tomber les tests unitaires tout autour, mais pas pour le code d'intégration.

La façon dont vous concevez ces wrappers les relie étroitement aux objets externes. À mon humble avis, c'est juste déplacer le problème/déplacer le code.

Ne pas recevoir les objets externes dans le constructeur et faire le mappage là. Tirez-le hors de tous ces objets, mais manipulez-le dans un code dont la seule responsabilité est de mapper la représentation du système externe vers la représentation interne.

C'est ainsi que vous conservez la dépendance par rapport au reste de votre code. J'aurais du code responsable de la communication avec la bibliothèque tierce, ce code n'expose pas les types que vous voulez garder du reste du système. Ne le cache pas non plus à l'intérieur d'autres objets, il les mappe directement ou appelle le code qui les mappe.