J'utilise le test de l'unité Microsoft et j'avez les suivants:
public class AccountCommandHandlers :
Handler<CreateAccountCommand>,
Handler<CloseAccountCommand>
{
public bool CreateAccountCommandWasCalled = false;
public bool CloseAccountCommandWasCalled = false;
public void Handle(CreateAccountCommand command)
{
CreateAccountCommandWasCalled = true;
}
public void Handle(CloseAccountCommand command)
{
CloseAccountCommandWasCalled = true;
}
}
[TestMethod]
public void CanRaiseInternalHandlers()
{
var iocContainer = SimpleInjectorWiringForMembus.Instance;
iocContainer.Bootstrap(
AppDomain.CurrentDomain.GetAssemblies());
var membus = MembusWiring.Instance;
membus.Bootstrap();
membus.Bus.Publish(new CreateAccountCommand() { Id = 100 });
membus.Bus.Publish(new CloseAccountCommand() { Id = 100 });
}
4 Réponses :
Voici une réponse plus "philosophique" à votre question: -)
Ma recommandation ne serait pas d'utiliser le conteneur IOO dans vos tests du tout, si possible!
Ma justification est que vous avez besoin de votre test pour avoir un contrôle total sur le contexte du test et qu'un CIO peut enlever une partie de ce contrôle. IMO, les tests unitaires doivent être aussi focalisés, petits et prévisibles que possible!
envisagez d'envoyer des objets simulés dans votre classe sous test, au lieu de classes réelles.
Si votre classe doit avoir une instance interne d'un conteneur COI, prenez la facteur de la classe dans un «contrôleur» de certaines sortes.
Vous pouvez y accomplir de plusieurs manières, mon être préféré d'utiliser un cadre comme Rhino Se moque .
De cette façon, vous aborderiez le «cycle de vie» fourni par le CIO au moment de l'exécution, dans votre test «Configuration».
Donc, le test doit avoir le contrôle total (à travers la moqueur et la mise au point) lorsque des objets sont créés ou détruits, en utilisant un cadre comme Rhino.
Vous pouvez vous moquer du CIO, si cela est nécessaire même.
comme une note latérale, l'un des avantages d'un conteneur de CIO bien conçu est qu'il devrait faciliter les tests de l'unité - car il devrait décourager les classes de s'appuyer sur des "instances concrètes" réelles des classes et encourage l'utilisation d'interfaces interchangeables à la place.
Vous devez essayer fier au moment de l'exécution sur le conteneur de la COI fournissant les implémentations concrètes des interfaces que vous avez conçues.
Notez qu'il est également normalement important de clarifier ce que vous testez réellement. Les tests d'unités doivent généralement se concentrer sur le test du comportement d'une seule méthode sur une seule classe.
Si vous testez réellement "plus" qu'une seule méthode sur une classe, par ex. Comment une classe interagit avec d'autres classes, cela signifie que vous écrivez probablement un test «d'intégration», pas un vrai test «unité».
Une autre note: je ne prétends pas être un expert au test unitaire! Ils sont incroyablement utiles, mais j'ai toujours du mal à tester plus que presque tout autre aspect du codage.
Pour plus de lecture, je recommande vivement "l'art des tests unitaires" de Roy Osherove. Il y en a d'autres aussi.
Ok cette réponse ressemble plus à un gros explosion sur les tests unitaires qu'une réponse à votre question très spécifique, désolé! J'espère que quelqu'un le trouve utile un jour :)
Je suis d'accord avec ce que vous dites ici, mais j'ai eu le sentiment que l'OP écrit réellement un test d'intégration pour vérifier si le système fonctionnerait correctement. Dans ces rares cas, vous souhaitez réellement tester l'infrastructure, y compris votre conteneur COI et y compris MEMBUS. Vous devriez probablement avoir une poignée de ces tests, mais néanmoins, ces tests sont importants à avoir.
Comme Steven dit dans ses commentaires, on dirait que vous écrivez un test d'intégration, auquel cas il est logique d'utiliser le conteneur de la COI.
Votre projet de test doit avoir sa propre composition pour la configuration de la COI. Vous pouvez configurer votre conteneur COI pour renvoyer un objet maquette pour CompteCommandHandLers. Votre test, plutôt que de vérifier les membres booléens, peut plutôt vérifier que la poignée (CreateCommand) a été appelée au moins une fois. Avec MOQ, il ressemblerait à ceci comme suit: si pour une raison quelconque, vous ne pouvez pas utiliser de maquette avec la configuration IOC, il serait facile de créer votre propre classe moquée pour ce cas d'essai.
Comme les autres ont déjà mentionné, vous exécutez des tests d'intégration. Ce n'est pas un problème cependant. Les tests d'intégration conviennent à tester vos paramètres CIO et à vous assurer que les différentes parties de votre application fonctionnent ensemble.
Avec un essai d'intégration Toutefois, vous ne devriez pas utiliser des objets simulés ou stubs. Les moqueurs et les talons ont leurs utilisations dans les tests unitaires. Un test unitaire consiste à tester la partie la plus petite possible de votre code. Dans un test unitaire, vous utilisez des simulacres pour contrôler le comportement de toutes les dépendances que votre classe a. J'ai écrit un blog il y a un an qui donne une introduction aux différences entre l'intégration et les tests d'unité et comment utiliser la moqueur dans vos tests.
Dans votre situation, je n'utiliserais pas le conteneur COI avec la configuration de la production pour la configuration de vos tests d'unité. Au lieu de cela, je basculerais pour créer manuellement vos objets dans vos tests et utiliser un outil moqueur comme MOQ pour contrôler les dépendances.
Mais c'est aussi quelque chose qui peut être automatisé. Un excellent outil est Autofixture . «Fixture» fait référence à la base dont vous avez besoin pour exécuter vos tests. Cela pourrait être des données d'échantillon, les moqueurs et les talons dont vous avez besoin et d'autres codes de configuration.
Mark Semelann (le développeur derrière Autofixture) a écrit un bon blog il y a quelques semaines à propos de l'utilisation de l'autofixe avec un CIO comme un Conteneur auto-moqueur . Je conseillerais d'utiliser quelque chose comme ceci pour structurer vos tests d'unité.
Une question que vous devriez aussi vous demander est: qu'est-ce que je veux réellement tester?
Votre suite de test ne doit pas nécessairement avoir besoin de tester des libs 3ème partie. Dans ce qui précède, Membus a été conçu pour délivrer les messages aux gestionnaires, les tests de cette bibliothèque garantissent que c'est le cas. P>
Si vous souhaitez vraiment tester le message -> Délégation du gestionnaire de la COOC, dans le cas de membus, vous pouvez écrire un bus -> adaptateur IOC pour tester: p> puis utilisez-le avec les instances sous test. P> var bus =
BusSetup.StartWith<Conservative>()
.Apply<IoCSupport>(
ioc => ioc.SetAdapter(new TestAdapter(new Handler<XYZ>()))
.SetHandlerInterface(typeof (IHandler<>)))
.Construct();
Bon point, mais il y a d'autres choses qui vont (sérialisation) sur pour d'autres tests (je n'ai pas inclus pour ne pas compliquer les choses), Membus n'est vraiment répertorié que non comme un artefact de l'essai amplifié. Membus est super btw :)