كيف يمكنني الاستمرار في استخدام DDD، TDD في BizTalk؟

Question

وأنا فقط بدأت الدخول في BizTalk في العمل وأحب أن الاستمرار في استخدام كل ما تعلمته عن DDD، TDD، الخ هل هذا ممكن حتى أو أنا دائما ستكون لدينا لاستخدام برنامج Visio مثل المحررين عند إنشاء أشياء مثل خطوط الأنابيب والتوزيعات الموسيقية؟

Answer 1

ويمكنك بالتأكيد ينطبق على الكثير من مفاهيم TDD وDDD إلى BizTalk التنمية.

ويمكنك تصميم وتطوير حول مفهوم كائنات المجال (على الرغم من أن في BizTalk والتنمية التكامل غالبا ما أجد الأشياء واجهة أو عقد أول تصميم ليكون وسيلة أكثر فائدة من التفكير - الحصول على تمرير ما الرسائل حولنا في واجهات بلدي). ويمكنك أيضا متابعة "بناء أبسط شيء ممكن أن سيعمل" و "بناء فقط الأشياء التي تجعل الاختبارات تمر" فلسفات TDD.

ولكن، يبدو سؤالك وكأنك تطلب المزيد عن الجانبين رمز تركز هذه النهج التصميم والتطوير.

هل أنا على حق ان كنت ترغب في أن تكون قادرة على اتباع نهج التنمية اختبار يحركها من كتابة أول اختبار أونتي تمارس شرط وفشل، ثم كتابة طريقة يلبي متطلبات ويتسبب في اختبار لتمرير - كل ذلك ضمن لغة برمجة التقليدية مثل C #؟

لذلك، للأسف، فإن الجواب هو لا. معظم القطع الأثرية BizTalk (خطوط الأنابيب والخرائط والتوزيعات الموسيقية ...) لا يمكن إلا أن يكون حقا بنيت باستخدام البصرية ستوديو الإضافات BizTalk. هناك طرق لعرض الكامنة ج # رمز، ولكن يمكن للمرء أبدا تريد أن تجرب وتطوير مباشرة هذا الرمز.

وهناك نوعان من أدوات BizUnit و <لأ href = "HTTP: //www.codeplex. كوم / bizunitextensions "يختلط =" نوفولو noreferrer "> ملحقات BizUnit التي تعطي بعض القدرة على التحكم في تنفيذ التطبيقات BizTalk و اختبارها ولكن هذا يحصل لك حقا فقط إلى النقطة أداء اختبار مدفوعة اختبارات التكامل أكثر وأكثر للرقابة .

والأشكال التي قمت بسحب على سطح التصميم التزامن سوف تفعل إلى حد كبير مجرد شيء الخاصة كوحدة واحدة مبهمة التنفيذ. والتوزيعات الموسيقية، وخطوط الأنابيب، والخرائط الخ ... وتهدف كل هذه الأمور إلى حد كبير ليتم تنفيذها (واختبار) ضمن الحل BizTalk بأكمله.

سوف

والممارسات التصميم الجيد (مع مؤشرات من النهج مثل TDD) يؤدي إلى كسر حلول BizTalk إلى المزيد من قطع أصغر، وحدات وقابلة للاختبار، وهل هناك طرق من الأشياء اختبار مثل خطوط الأنابيب في العزلة.

ولكن تفاصيل مفصلة من TDD وDDD في التعليمات البرمجية للأسف لا تترجم.

لبعض المناقشات ذات الصلة التي قد تكون مفيدة ترى هذا السؤال:

الاستهزاء خدمة ويب التي يستهلكها Biztalk طلب استجابة ميناء

Answer 2

إذا كنت غالبا ما تجعل استخدام خطوط الأنابيب ومكونات خطوط أنابيب مخصصة في BizTalk، قد تجد مكتبة PipelineTesting بلدي مفيدة. انها تسمح لك لاستخدام NUnit (أو أي إطار اختبار أخرى كنت تفضل ذلك) لإنشاء اختبارات مؤتمتة لخطوط الأنابيب كاملة، مكونات خط أنابيب محددة أو حتى المخططات (مثل المخططات ملف ثابت).

وانها مفيدة جدا إذا كنت تستخدم هذا النوع من الوظائف، إذا جاز لي أن أقول ذلك لنفسي (I جعل الاستخدام الكثيف منه على مشاريع بلدي).

ويمكنك أن تجد مدخلا إلى مكتبة هنا ، ورمز كامل على جيثب . وهناك أيضا بعض الوثائق أكثر تفصيلا عن دورتها يكي .

Answer 3

وأنا أتفق مع تصريحات CKarras. وقد استشهد كثير من الناس أن كسبب لمدة لا تروق إطار BizUnit. ولكن إلقاء نظرة على BizUnit 3.0. ويحتوي على نموذج الكائن الذي يسمح لك لكتابة خطوة اختبار كاملة في C # / VB بدلا من XML. تم ترقيته BizUnitExtensions إلى طراز كائن جديد أيضا.

ومزايا النظام القائم XML هي أنه من الأسهل لتوليد خطوات اختبار وليس هناك حاجة إلى إعادة ترجمة عند تحديث الخطوات. في بلدي مكتبة الإضافات الخاصة، وجدت XmlPokeStep (مستوحاة من نانت) أن تكون مفيدة جدا. فريقي يمكن تحديث اختبار خطوة أكس على الطاير. على سبيل المثال، دعونا نقول كان علينا أن ندعو إلى خدمة ويب التي خلقت سجل عميل ومن ثم فحص قاعدة بيانات لهذا السجل نفسه. الآن إذا عاد خدمة ويب معرف (ديناميكيا)، ونحن يمكن تحديث خطوة اختبار لاتخاذ الخطوة التالية على الطاير (وليس في نفس ملف xml طبعا) ومن ثم استخدام ذلك للتحقق من قاعدة البيانات.

ومن منظور الترميز، ينبغي معالجة التحسس الآن في BizUnit 3.0. عدم وجود XSD لم يجعل الأمور صعبة في الماضي. أنا على أمل الحصول على XSD من شأنها أن تساعد في التحسس. وكانت هناك بعض قصاصات فضلا عن نسخة قديمة من BizUnit لكن تم تحديث هذه طعاما، ربما لو ثيريس الوقت سأعطيك أن الذهاب.

ولكن بالعودة إلى قضية TDD، إذا كنت تأخذ بعض من وراء القصد TDD - مواصفات أو السلوك يقودها عنصر، ثم يمكنك تطبيقه إلى حد ما في التنمية Biztalk كذلك لأنه يعتمد BizTalk بشكل كبير على تطوير العقد مدفوعة . بحيث يمكنك تحديد الواجهات الخاصة بك أولا وإنشاء التوزيعات الموسيقية كعب الخ لمعالجتها ومن ثم بناء من جوهر. هل يمكن أن يكتب الاختبارات BizUnit في ذلك الوقت. وأود أن هناك بعض الأدوات التي يمكن أتمتة هذه العملية ولكن الآن هناك تخلخل.

<ع> استخدام أطر مثل التوجيه ESB يمكن أن تساعد أيضا تعطيك منصة قاعدة للعمل خارج حتى تتمكن من تنفيذ حالات الاستخدام الرئيسية من خلال النظام الخاص بك بشكل متكرر.

وفقط عدد قليل من الأفكار. أتمنى أن يساعدك هذا. وأعتقد أن لها قيمة المدونات عن أكثر على نطاق واسع. هذا هو موضوع جيد للdiscuss.Do بينغ لي إذا كان لديك أي أسئلة أو يمكن أن نناقش دائما أكثر أكثر من هنا.

وRGDS بنجي

Answer 4

هل يمكن استخدام BizUnit لإنشاء وإعادة استخدام حالات الاختبار العامة في كل من رمز والتفوق (لسيناريوهات الوظيفية)

http://www.codeplex.com/bizunit

ومن المتوقع أن يكون أكثر IDE متكاملة قابلية الاختبار

وBizTalk خادم عام 2009.

وهتاف Hemil.

Answer 5

وBizUnit هو حقا الألم لاستخدام لجميع اختبارات مكتوبة في XML بدلا من لغة البرمجة.

في مشاريعنا، لدينا أجزاء "استدار" من BizUnit إلى C # إطار اختبار سهل القديمة. هذا يتيح لنا استخدام مكتبة BizUnit من خطوات مباشرة في C # رمز NUnit / MSTest. وهذا يجعل من الاختبارات التي هي أسهل في الكتابة (باستخدام VS التحسس)، أكثر مرونة، والأهم من ذلك، وأسهل للتصحيح في حال فشل الاختبار. العيب الرئيسي لهذا النهج هو أن لدينا متشعب من المصدر الرئيسي BizUnit.

وآخر خيار للاهتمام أود أن تنظر للمشاريع المستقبلية هو BooUnit ، وهو المجمع بو على رأس من BizUnit. لديها مزايا مماثلة لدينا BizUnit "الميناء"، ولكن أيضا لديه ميزة لا تزال تستخدم BizUnit بدلا من التفرع منه.