Répondre

2

Vous pouvez certainement appliquer un grand nombre des concepts de TDD et de DDD au développement de BizTalk. Vous pouvez concevoir et développer autour du concept d'objets de domaine (bien que dans BizTalk et le développement d'intégration, je trouve souvent les objets d'interface ou le premier design de contrat plus utiles - quels messages sont transmis à mes interfaces). Et vous pouvez également suivre la «Construire la chose la plus simple possible qui fonctionne» et «construire seulement des choses qui font passer les tests» philosophies de TDD. Toutefois, votre question semble être que vous vous interrogez 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 suivre l'approche de développement pilotée par les tests en écrivant d'abord un test unti exigeant et échouant, puis en écrivant une méthode qui répond aux exigences et qui fait passer le test? dans une langue de programmation traditionnelle comme C#?

Pour cela, malheureusement, la réponse est non. La majorité des artefacts BizTalk (pipelines, cartes, orchestrations ...) ne peuvent vraiment être générés en utilisant les plugins BizTalk Visual Studio. Il existe des moyens 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 BizUnit Extensions qui permettent de contrôler l'exécution des applications BizTalk et de les tester, mais cela ne vous empêche pas d'effectuer davantage de tests d'intégration contrôlés et basés sur les tests.

Les formes que vous faites glisser sur la surface de conception d'Orchestration feront largement leur travail en tant qu'unité d'exécution opaque. Et Orchestrations, pipelines, cartes, etc ... toutes ces choses sont en grande partie destinées à être exécutées (et testées) dans toute une solution BizTalk. De bonnes pratiques de conception (prenant des pointeurs à partir d'approches telles que TDD) conduiront à décomposer les solutions BizTalk en blocs plus petits, plus modulaires et testables, et il existe des moyens de tester des éléments tels que les pipelines isolés.

Mais les détails détaillés de TDD et DDD dans le code ne traduisent malheureusement pas.

Pour une discussion à ce sujet qui peut être utile voir cette question:

Mocking WebService consumed by a Biztalk Request-Response port

+0

Merci beaucoup pour votre réponse. Je suis content qu'il y ait des choses comme BizUnit et les extensions BizUnit. Je vais donner à ceux-ci un coup de feu. –

0

Vous pouvez utiliser BizUnit pour créer et réutiliser des cas de test génériques en code et Excel (pour les scénarios fonctionnels)

On s'attend à ce que BizTalk Server 2009 ait plus de testabilité intégrée à l'environnement d'EDI (BizTalk Server 2009).

Cheers Hemil.

1

Si vous utilisez souvent des pipelines et des composants de pipeline personnalisés dans BizTalk, vous pouvez 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 pour des pipelines complets, des composants de pipeline spécifiques ou même des schémas (tels que des schémas de fichiers plats).

C'est très utile si vous utilisez ce genre de fonctionnalité, si je peux me permettre de le dire moi-même (j'en fais un usage intensif sur mes propres projets). Vous pouvez trouver une introduction à la bibliothèque here, et le code complet sur github. Il y a aussi une documentation plus détaillée sur son wiki.

0

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é" des parties de BizUnit sur un ancien 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 (à l'aide de VS Intellisense), plus souples et, surtout, plus faciles à déboguer en cas d'échec du test. Le principal inconvénient de cette approche est que nous avons dérivé de la source principale de BizUnit.

Une autre option intéressante que je considérerais pour les futurs projets est BooUnit, qui est un emballage Boo au-dessus de BizUnit. Il présente des avantages similaires à notre "port" BizUnit, mais il a aussi l'avantage d'utiliser BizUnit au lieu d'en forcer.

1

Je suis d'accord avec les commentaires de CKarras. Beaucoup de gens ont cité cela comme leur raison de ne pas aimer le cadre BizUnit. Mais jetez un oeil à BizUnit 3.0. Il a un modèle d'objet qui vous permet d'écrire toute 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é par NAnt) très utile. Mon équipe a pu mettre à jour l'étape de test xml à la volée. Par exemple, disons que nous devions appeler un service Web qui créait un enregistrement client, puis vérifiions une base de données pour ce même enregistrement. Maintenant, si le webservice renvoyait l'ID (généré dynamiquement), nous pourrions mettre à jour l'étape de test pour la prochaine étape à la volée (pas dans le même fichier xml bien sûr) et ensuite l'utiliser pour vérifier la base de données. Du point de vue du codage, l'intellisense devrait maintenant être adressée dans BizUnit 3.0. L'absence d'un XSD a rendu les choses difficiles dans le passé. J'espère obtenir 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 si le temps passe, je vais essayer. Mais pour en revenir au problème TDD, si vous prenez en compte l'intention derrière TDD - l'élément piloté par 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 contrat. développement. Vous pouvez donc d'abord spécifier vos interfaces et créer des orchestrations de stub, etc. pour les gérer, puis construire le noyau. Vous pouvez écrire les tests BizUnit à ce moment-là. J'aurais aimé qu'il y ait des outils qui pourraient automatiser ce processus, mais pour l'instant, il n'y en a pas. L'utilisation de frameworks tels que le guidage ESB peut également vous aider à travailler sur une plate-forme de base afin de pouvoir 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 d'en parler plus longuement. Ceci est un bon sujet à discuter. Do ping-moi si vous avez des questions ou nous pouvons toujours discuter plus ici.

Mfg Benjy