Cuke4Nuke أو SpecFlow?

Question

أنا أحاول أن تقرر ما إذا كان يجب استخدام Cuke4Nuke أو SpecFlow.ما هي pro/سلبيات كل منها ؟ الآراء حول أيهما أفضل ولماذا ؟

وذلك بفضل!

Answer 1

(قد أكون متحيزًا لأنني متورط في Specflow ، لكن هنا أفكاري ...)

Cuke4nuke قريب جدا من الخيار. هذا يعد بالكثير من المزايا:

• التوافق
• الحصول على ميزات جديدة من الخيار عندما يتطور الخيار (على الأقل من الناحية النظرية ، لكن دعم اللغة مثال على ذلك)
• كونك جزءًا حقيقيًا من مجتمع الخيار والنظام الإيكولوجي للخيار

ومع ذلك ، يأتي هذا أيضًا مع بعض العيوب المحتملة:

• روبي ضرورة
• نظرًا لأن المزيد من البنية التحتية (Ruby و Wire-Protocol وتكامل خط الأوامر ...) متورط ، فإن تعقيد الحل كله يرتفع ، وفرص أن يكون هناك شيء ما في السلسلة في الارتفاع
• تصحيح الأخطاء ممكن ولكن قليلا من أ مشاحنة
• يعد تشغيل السيناريوهات على DOS-Commandline مجرد قبيح ، وما زلت أواجه مشاكل مع بعض الشخصيات (Umlaute الألمانية). ال حلول من الخيار لم يعمل مع Cuke4nuke في حالتي.
• التكامل مع بناءك المستمر هو شيء عليك أن تعمل بنفسك

Specflow هو مشروع منفصل عن الخيار. يحاول أن يكون أقرب ما يكون إلى الخيار ، ولكن هناك ثغرات وستكون. هناك خطط لاستخدام نفس المحلل المحلل مثل الخيار ، لتحسين التوافق على مستوى اللغة.

يحاول Specflow تقديم المزايا التالية:

• حل .NET نقي (لذلك لا يوجد تثبيت من روبي ضروري ولا يشارك روبي في وقت التشغيل)
• هناك تكامل أساسي مع VisualStudio (وهناك خطط لتطوير هذا)
• السيناريوهات هي في الأساس لا تُعرف بالبنية التحتية الحالية (Nunit.Runners ، Resharper ، VisualStudio MSTEST Integration ...)
• يمكن تصحيح السيناريوهات والخطوات بسهولة من VisualStudio (فقط اضبط نقطة توقف)
• يجب أن يكون التكامل في بنيتك المستمرة نسيمًا ، لأن البنية التحتية لتشغيل اختبارات الوحدة هي بالتأكيد موجودة بالفعل

كعيوب للمواصفات التي أراها حاليا:

• لا يدعم العديد من اللغات مثل الخيار
• يوجد حاليًا خطوة "توليد الكود". هذا شفاف عند استخدام VisualStudio ، وهناك سطر أوامر للقيام بذلك بدون VisualStudio ، لكن الكثير من الناس لا يحبون توصيل الكود.
• لا يوجد حاليًا عداء سطر أوامر صريح لـ Specflow. ومع ذلك ، يمكنك استخدام عداء خط الأوامر للاختبار الخاص بك.
• يعتمد Specflow على إطار اختبار الوحدة ، ويتم دعم Nunit و MSTEST حاليًا فقط
• الإبلاغ في Specflow ليس متطورًا جدًا بعد. يقدم الخيار المزيد من الخيارات ، لكنني لا أعرف ما إذا كانت جميعها متوفرة في Cuke4Nuke ...

Answer 2

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

الهدف من Cuke4Nuke هو توافق الخيار الكامل في .NET مع تكرار كود القليل من كود الخيار. لذلك ، فإن بعض المقايضات التي أبرزتها-وقد تم تأكيد التبعية روبي-للأداة. البعض الآخر ، مثل الأخطاء في اللغة والدعم المنسق ودعم تصحيح الأخطاء المحدودة ، هي قضايا مؤقتة وستذهب مع الإصدارات المستقبلية.

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

Answer 3

رأي آخر متحيز للغاية: حاول قصة :)

اختبارات StoryQ هي في الواقع رمز ، لذلك يمكنك الحصول على دعم أفضل بكثير من إعادة النمو / IDE ، وتدمج في عداء اختبار الوحدة الحالي الخاص بك ، لذلك CI هو نسيم.

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

يوجد في الواقع واجهة المستخدم الرسومية من شأنه أن يحول سيناريوهات النص العادي إلى رمز StoryQ لك ، إذا كنت قد حصلت بالفعل على استثمار في سيناريوهات النص العادي أو إذا كنت ترغب في إعطاء لوحة المفاتيح لعمليات عملك. حتى أنه لديه شكل بسيط من Intellisense!

امنحها إذا كنت تريد نقطة دخول خفيفة للغاية في BDD :)

Answer 4

آخر منحازة الرد: StorEvil يأكل كل الأخرى .صافي BDD الأدوات.

مزايا:StorEvil الخاصة سطر الأوامر عداء جميلة التقارير (باستخدام الشرارة عرض المحرك) ، أفضل نص عادي->C# الترجمة والتنفيذ المحرك.

أيضا ، فقد 100% أكثر شرا من أي حل آخر.

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

Answer 5

أنا أفهم من ريتشارد أنه يعتزم وقف cuke4nuke ويدعم نقل بعض ميزات cuk4nuke إلى specflow. لذا فإن الإجابة الواضحة الآن هي Specflow.

Answer 6

لقد بدأت مع Cuke4Nuke ولكن منذ ذلك الحين انشقت إلى Specflow (آسف ريتشارد ؛-)

الأسباب الرئيسية التي أدت إلى إجراء هذا الانتقال هي:

• يحتوي Specflow على تكامل VS2010 لطيف لتسليط الضوء على بناء الميزات. هناك مشروع Cuke4VS يقدم مماثلًا ولكنه لم يكن لديه دعم VS2010 (أو لا عندما نظرت آخر مرة على أي حال ، وهو ما كان حديثًا إلى حد ما)
• لقد وجدت أن اختبارات تصحيح الأخطاء في Specflow أسهل (لا تطلب مني أن أشرح ، بدا الأمر بهذه الطريقة ... ؛-)
• Cuke4nuke بحاجة إلى روبي. كنت موافقًا على ذلك ، لكن معظم c# devs أعرفها تتعثر من أي منتجات غير MS ، روبي على وجه الخصوص.

هناك بعض المشكلات المتعلقة بـ Specflow/الأشياء التي أحبها بشكل أفضل في عالم الخيار/cuke4nuke:

• وثائق Specflow هي "lite" تمامًا - يجب أن تكون مستعدًا للعمل بجد لجمع المعلومات من مصادر الخيار والتكنولوجيا قليلاً كيف تنطبق على Specflow. هذا ما قاله نفسي وعدد قليل من الآخرين لديهم تصميمات على تعزيز الوثائق بحيث قد تتحسن خلال الأشهر القليلة المقبلة.
• أفضّل كثيرًا تجربة تشغيل اختبارات Cucumber/Cuke4Nuke على سطر الأوامر مع إخراجها من الألوان السيناريوه شاب...)
• مجتمع الخيار أكبر ، وهناك المزيد من النشاط الذي يبدو (ربما) يترجم إلى المزيد من الناس هناك لمساعدتك.

الكل في كليهما لديه إمكانية تحسين الطريقة التي نكتب بها البرامج.