2010-03-12 3 views
4

Essayant simplement de mettre en œuvre des tests unitaires dans un système de type brownfield. Sachez que je suis relativement nouveau dans le monde des tests unitaires. Ce sera une migration progressive, bien sûr, car il y a tellement de zones de douleur.Est-ce que le CIO va résoudre nos problèmes?

Le problème actuel que j'essaie de résoudre est que nous avons suivi beaucoup de mauvaises pratiques de nos jours VB6 et dans la conversion de notre application à .Net. Nous avons BEAUCOUP de beaucoup de fonctions partagées/statiques qui appellent d'autres fonctions partagées et celles qui appellent les autres et ainsi de suite. Parfois, les dérives sont transmises en tant que paramètres et parfois elles viennent juste d'être ajoutées dans la fonction appelante. J'ai déjà demandé à nos développeurs d'arrêter de créer des fonctions partagées et de créer à la place des membres d'instance et d'utiliser uniquement ces membres d'instance hors des interfaces, mais cela n'atténue pas la situation actuelle. Donc, vous devez passer récursivement dans chaque dépendance à la couche supérieure pour chaque fonction dans votre chemin de code et les signatures de méthodes se transforment en désordre. J'espere que c'est quelque chose que IOC va corriger. Actuellement, nous utilisons NUnit/Moq et je commence à étudier StructureMap. Je comprends à ce jour que vous avez assez bien dit StructureMap pour l'interface x je veux par défaut à la classe de béton y:

ObjectFactory.Initialize(x=>{x.ForRequestType<IInterface>().TheDefaultIsConcreteType<MyClass>()}); 

Puis exécution:

var mytype = ObjectFactory.GetInstance<IInterface>(); 

le conteneur du CIO initialiser le type correct pour toi. Je ne sais pas encore comment échanger un faux pour le type de béton mais j'espère que c'est simple. La COI va-t-elle résoudre les problèmes dont je parlais plus haut? Y a-t-il un cadre spécifique du CIO qui le fera mieux que StructureMap ou peuvent-ils tous gérer cette situation? Toute aide serait très appréciée.

Répondre

4

À peu près, ce n'est pas une solution miracle.

Notez que le conteneur IOC doit être défini à la racine de votre application. Pas ad-hoc. Sinon, vous implémenteriez un localisateur de service qui est un anti-pattern.

Suivez l'injection de construction pour votre code de production, laissez le conteneur IOC résoudre vos dépendances. Pour les tests unitaires, il vous suffit de coder en dur vos dépendances. Cela vous permettra d'utiliser des objets simulés (doubles de test). En d'autres termes, IOC n'a rien à voir avec les tests unitaires.

+0

Merci pour la réponse Finglas. Qu'est-ce que tout cela ressemble? Est-ce qu'il élimine tous les paramètres de dépendance dans chaque appel de méthode? Comment passez-vous facilement des faux pour chaque dépendance lorsque vous faites votre test unitaire? – coding4fun

+0

En fait était confus sur ce qu'est vraiment un IoC. Comme vous l'avez indiqué ci-dessus, vous n'utilisez pas l'IoC pour le code de test uniquement pour le code de production.Vous continuez d'utiliser l'injection de constructeurs, mais vous n'utilisez que l'IoC. Vous n'avez donc pas besoin de vous asseoir et de faire passer tous ceux qui utilisent votre classe dans chaque paramètre. Ce qui m'a aidé à comprendre IoC est de regarder un screencast avec James Kovacs à DnrTV qui l'impliquait dans la construction de son propre conteneur IoC. Très intéressant!! Hmm je ne sais pas combien IoC va aider dans ce cas. Le graphique de dept/initialisation est partout. – coding4fun

+0

Vous ne serez pas en mesure de tout faire en un seul coup, mais avec un peu de planification, vous devriez pouvoir y arriver progressivement. Cela pourrait signifier créer moins de joli code dans les phases intermédiaires, mais ne vous découragez pas, cela peut être fait :) bonne chance! –

1

IoC est excellent pour se débarrasser des méthodes statiques et éviter la délégation de dépendance, car il est facile pour chaque classe de déclarer explicitement toutes les dépendances.

Comme pour les tests unitaires, il y a deux camps:

  • Insérer des simulacres cas pour les dépendances dans le conteneur du CIO, que vous ne souhaitez pas tester dans un cas particulier, et que la détermination du récipient comme d'habitude. Cela fonctionne particulièrement bien si vous voulez tester plusieurs classes en tant que composant intégré.
  • Mockez toutes les instances dont vous avez besoin pour construire un seul objet d'une classe afin de les tester et de les insérer manuellement. Cela fonctionne particulièrement bien si vous voulez coller à tester chaque classe individuellement (votre unité est une seule classe)
Questions connexes