Question

Après plusieurs années de suite à la mauvaise pratique transmise de « architectes » à mon lieu de travail et de penser qu'il doit y avoir une meilleure façon, je l'ai lu récemment autour TDD et DDD et je pense que les principes et les pratiques serait un grand ajustement pour la complexité des logiciels que nous écrivons.

Cependant, la plupart des échantillons TDD j'ai vu appeler une méthode sur l'objet de domaine, puis les propriétés de test de l'objet pour assurer le comportement exécuté correctement.

Par contre, plusieurs personnes respectées dans l'industrie (Greg Young le plus nettement si ses discussions sur CQRS) préconisent l'encapsulation entièrement chaque objet de domaine en supprimant tous les « apporteurs ».

Ma question est donc: Comment peut-on tester la fonctionnalité d'un objet de domaine s'il est interdit de récupérer son état

?

Je crois que je manque quelque chose de fondamental si s'il vous plaît ne hésitez pas à me appeler un idiot et me éclairer -. Toute orientation serait grandement apprécié

Était-ce utile?

La solution

Qu'est-ce que vous décrivez est vérification de l'état dans laquelle vous VALOIR sur l'état de l'objet de domaine. Il y a une branche de TDD qui est appelé vérification du comportement qui utilise des objets Mock.

vérification de comportement vous permet de spécifier quelles méthodes doivent appeler et si vous voulez, les méthodes ne sont pas appelés.

Regardez dans cet article par Martin Fowler pour plus de détails: Mocks Ne sont pas Stubs .

Autres conseils

OK, cette réponse est d'un an trop tard; -)

Mais quand vous voulez tester les modèles CQRS, vous pouvez faire des affirmations sur les événements de domaine tirés au lieu des affirmations sur l'état de l'entité.

par exemple. si vous voulez tester si vous appelez. customer.Rename ( « Foo ») se traduit par le comportement correct

Au lieu de test si customer.Name est égal à « foo », vous testez plutôt s'il y a un événement CustomerRename en attente avec la valeur « Foo » dans votre magasin d'événements en attente. (Dans votre UOW ou dans votre liste d'événements d'entité en fonction de la mise en œuvre)

Si vous allez vraiment aller aussi loin que d'interdire la récupération de l'Etat, alors vous serez limité à des tests de comportement, probablement par un cadre moqueur, comme Typemock, qui a le pouvoir de suivre le comportement de votre objet. Si vous êtes capable de faire pur BDD, vous pouvez théoriquement affirmer la justesse de votre système dans son ensemble par la façon dont il se comporte.

Dans la pratique, j'ai trouvé BDD être plus fragile dans beaucoup de cas que les tests juste stateful. Alors que certaines personnes pourraient appeler à une certaine théorie, il ne fonctionne que si cela fonctionne pour vous. tests basés sur l'état représente encore 90% de tous les tests unitaires que nous écrivons, et nous sommes bien conscients de BDD sur notre équipe.

Faire ce qui fonctionne le mieux pour vous.

Un couple de choses.

Tout d'abord, quand vous faites des choses comme TDD pour rendre votre code testable vous vous retrouvez avec plus petite classe. Si vous avez une classe avec beaucoup de propriétés privées que vous ne pouvez pas inspecter, theres une bonne chance il pourrait être divisé en plusieurs classes et a fait plus testable.

En second lieu, oldschool architecture OO essaie de rendre le logiciel en toute sécurité en utilisant les garanties linguistiques pour empêcher les choses d'être accessibles. Une architecture TDD rend le logiciel plus robuste en écrivant des tests qui vérifient ce que le code ne fait, en mettant moins l'accent sur l'utilisation de la langue des constructions pour assurer ce que le programme ne fait pas.

Enfin, la vérification d'une propriété n'est pas la seule façon de valider le code fait ce qu'il était censé faire. Le livre xUnit design documents Patterns autres approches ici: http://xunitpatterns.com/Result%20Verification% 20Patterns.html

J'appelle les méthodes d'entrée publiques d'un système (à savoir que je pousse des données d'entrée dans le système), puis je reçois (et affirme) la sortie du système. Je ne suis pas tester l'état interne du système, mais plutôt son comportement public / visible: Si un essai interne mise en œuvre, ou tester uniquement le comportement du public?

Ce que vous mentionnez que l'on appelle le test de l'Etat. Il y a aussi des tests de comportement. Les techniques utilisées pour cette injection de dépendance sont, l'inversion de contrôle et Mocking:

Tous les effets secondaires de votre classe sont mises en œuvre comme invocations de méthode sur ses « dépendances » - à savoir les objets fournis de l'extérieur, le plus souvent dans le constructeur. Ensuite, dans votre unité test, vous fournissez un objet faux au lieu d'un vrai. L'objet de faux peut se rappeler si sa certaine méthode a été appelée, et c'est ce que vous prétendez dans votre test.

Il existe nombre de cadres Mocking qui automatisent la maquette création d'objets en générant dynamiquement des classes qui mettent en œuvre une interface donnée. Les plus populaires sont Rhino.Mocks et Moq.

Hey Justin, comme toi, j'étais récemment pensé à ajouter getters à mon objet de domaine en écriture seule pour le bien des tests unitaires, mais maintenant je suis convaincu que je me suis trompé. En supposant que vous avez acheté dans l'idée d'un domaine en écriture seule, en premier lieu, alors si vous avez getters du tout, vous demandez des ennuis. Le principe de domaine en écriture seule voudrait que vous déclencher un événement de votre objet de domaine, ou lire à partir d'une projection que votre objet de domaine écrit, ou quelque chose comme ça. Une fois que vous exposez getters vous commencez à exposer « la forme » de l'objet, et comme le dit Greg Young, « objets de domaine ont un comportement, pas de forme ».

Cela étant dit, je me bats avec ce même question ... comment faire l'unité test, vous un objet de domaine en écriture seule? Voici mon plan actuel: Je pense à faire mon feu objet de domaine un dicton événement de domaine « Ces propriétés ont changé », et dans mon test unitaire, je vais inscrire à ce avant d'envoyer la « EditCommand ». Consultez le poste de Udi Dahan sur les événements de domaine ici et voir aussi ce que Eric Evans dit au sujet des événements du domaine .

Je me demandais la même chose jusqu'à ce que je suis tombé sur les papiers suivants. Je les ai trouvés grandes amorces sur l'exécution de vérification de comportement, en particulier le premier me fournir plusieurs « moments aha »:

  1. aide Mocks et des tests pour concevoir des objets basés sur les rôles
  2. rôles Mock, pas des objets
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top