Comment puis-je toujours utiliser DDD, TDD dans BizTalk?

Question

Je viens tout juste de commencer à utiliser BizTalk au travail et j'aimerais continuer à utiliser tout ce que j'ai appris sur DDD, TDD, etc. Est-ce même possible ou vais-je toujours devoir utiliser Visio comme des éditeurs pour créer pipelines et orchestrations?

Answer 1

Vous pouvez certainement appliquer bon nombre des concepts de TDD et de DDD au développement de BizTalk.

Vous pouvez concevoir et développer le concept des objets de domaine (bien que dans BizTalk et le développement de l'intégration, les objets d'interface ou la conception à contrat sont souvent un moyen plus utile de penser: quels messages sont transmis à mes interfaces). Et vous pouvez également suivre les philosophies de la TDD "Construire la chose la plus simple possible qui fonctionne" et "Construire uniquement les choses qui font que les tests passent".

Cependant, votre question donne l'impression que vous en demandez davantage sur les aspects centrés sur le code de ces approches de conception et de développement.

Ai-je raison de dire que vous aimeriez pouvoir suivre l'approche de développement piloté par les tests consistant à écrire d'abord un test qui exerce une exigence et échoue, puis à écrire une méthode qui satisfait à l'exigence et fait en sorte que le test réussisse? un langage de programmation traditionnel comme C #?

Pour cela, malheureusement, la réponse est non. La majorité des artefacts de BizTalk (pipelines, cartes, orchestrations, etc.) ne peuvent réellement être construits qu'à l'aide des plug-ins Visual Studio BizTalk. Il existe différentes manières de visualiser le code c # sous-jacent, mais on ne voudrait jamais essayer de développer directement ce code.

Il existe deux outils BizUnit et Extensions de BizUnit qui permettent de contrôler l’exécution des applications BizTalk et de les tester, ce qui vous permet d’effectuer des tests d’intégration plus contrôlés et plus contrôlés. .

Les formes que vous faites glisser sur la surface de conception d’Orchestration ne feront en grande partie que leur fonction en tant qu’unité d’exécution opaque. Et les orchestrations, les pipelines, les cartes, etc. ... tous ces éléments sont en grande partie destinés à être exécutés (et testés) au sein d’une solution BizTalk complète.

De bonnes pratiques de conception (en prenant des pointeurs d’approches telles que TDD) permettront de scinder les solutions BizTalk en blocs plus petits, plus modulaires et testables. Il existe également des méthodes pour tester des éléments tels que les pipelines.

Mais les spécificités détaillées de TDD et DDD dans le code ne sont malheureusement pas traduites.

Pour une discussion connexe qui pourrait être utile, consultez cette question:

Service Web moqueur consommé par une requête-réponse Biztalk port

Answer 2

Si vous utilisez souvent des pipelines et des composants de pipeline personnalisés dans BizTalk, vous pourrez trouver ma propre bibliothèque PipelineTesting utile. Il vous permet d’utiliser NUnit (ou tout autre framework de test que vous préférez) pour créer des tests automatisés de pipelines complets, de composants de pipeline spécifiques ou même de schémas (tels que des schémas de fichiers plats).

C’est très utile si vous utilisez ce type de fonctionnalité, si je puis me permettre de le dire moi-même (je l’utilise beaucoup dans mes propres projets).

Vous pouvez trouver une introduction à la bibliothèque ici . et le code complet sur github . Il existe également une documentation plus détaillée sur son wiki .

Answer 3

Je suis d’accord avec les commentaires de CKarras. De nombreuses personnes ont cité cette raison pour ne pas aimer le framework BizUnit. Mais jetez un oeil à BizUnit 3.0. Il a un modèle objet qui vous permet d'écrire l'intégralité de l'étape de test en C # / VB au lieu de XML. BizUnitExtensions est également mis à niveau vers le nouveau modèle d'objet.

Les avantages du système XML sont qu’il est plus facile de générer des étapes de test et qu’il n’est pas nécessaire de recompiler lorsque vous mettez à jour les étapes. Dans ma propre bibliothèque Extensions, j’ai trouvé le XmlPokeStep (inspiré de NAnt) très utile. Mon équipe pourrait mettre à jour l'étape de test XML à la volée. Par exemple, supposons que nous ayons dû appeler un service Web ayant créé un enregistrement client, puis vérifié le même enregistrement dans une base de données. Maintenant, si le service Web a renvoyé l’ID (généré de manière dynamique), nous pourrions mettre à jour l’étape de test pour l’étape suivante à la volée (pas dans le même fichier xml bien sûr), puis l’utiliser pour vérifier la base de données.

Du point de vue du codage, l'intellisense devrait maintenant être traité dans BizUnit 3.0. L'absence de XSD a rendu les choses difficiles par le passé. J'espère sortir un XSD qui aidera l'intellisense. Il y avait aussi des extraits pour une ancienne version de BizUnit, mais ceux-ci n’ont pas été mis à jour, peut-être que si le temps me le permet, je vais essayer.

Mais pour revenir à la question TDD, si vous prenez une partie de l'intention derrière TDD - l'élément basé sur la spécification ou le comportement, vous pouvez également l'appliquer dans une certaine mesure au développement de Biztalk, car BizTalk est fortement basé sur le développement dirigé par contrat. . Vous pouvez donc d'abord spécifier vos interfaces et créer des orchestrations de stub, etc. pour les gérer, puis créer le noyau. Vous pourriez écrire les tests BizUnit à ce moment-là. J'aimerais que certains outils permettent d'automatiser ce processus, mais pour l'instant, il n'y en a pas.

L'utilisation de frameworks tels que le guide ESB peut également vous aider à disposer d'une plate-forme de base sur laquelle vous pourrez travailler, ce qui vous permet d'implémenter les principaux cas d'utilisation via votre système de manière itérative.

Juste quelques réflexions. J'espère que cela t'aides. Je pense que cela vaut la peine de bloguer plus longuement. C’est un bon sujet à discuter. Si vous avez des questions, n'hésitez pas à me contacter si nous pouvons toujours en discuter davantage ici.

Rgds Benjy

Answer 4

Vous pouvez utiliser BizUnit pour créer et réutiliser des scénarios de test génériques à la fois dans le code et dans Excel (pour les scénarios fonctionnels)

http://www.codeplex.com/bizunit

BizTalk Server 2009 devrait avoir une plus grande testabilité intégrée dans l'EDI.

A bientôt Hemil.

Answer 5

BizUnit est vraiment difficile à utiliser car tous les tests sont écrits en XML au lieu d’un langage de programmation.

Dans nos projets, nous avons " porté "" certaines parties de BizUnit à un ancien et simple framework de test C #. Cela nous permet d'utiliser la bibliothèque d'étapes de BizUnit directement dans le code C # NUnit / MSTest. Cela rend les tests plus faciles à écrire (avec VS Intellisense), plus flexibles et surtout, plus faciles à déboguer en cas d'échec du test. Le principal inconvénient de cette approche est que nous avons créé un fork depuis la source principale de BizUnit.

Une autre option intéressante que je considérerais pour les projets futurs est BooUnit , qui est un wrapper Boo au-dessus. de BizUnit. Il présente des avantages similaires à notre "port" BizUnit, mais présente également l’avantage de continuer à utiliser BizUnit au lieu de le remplacer.