Autofixture: اقتراح: اتبع أسلوب "Arrange Act Assert" للاختبارات

أذهب خلفها. لكني أفضل أن يكون أول حرف كبير ، أي

// Arrange
// Act
// Assert

بدلا من

// arrange
// act
// assert

هل لديك أسباب قوية لتفضيل الحالة الثانية؟

لا ، الأحرف الكبيرة جيدة بالنسبة لي - يكفي أن نستخدم AAA: أحمر الخدود:

يمكنك أيضًا فصل كل مرحلة بسطر فارغ ، وهو التنسيق الذي أستخدمه في الوقت الحاضر. بعد ذلك ، يمكن لقارئ الاختبار أن يفترض أنه معطى / متى / بعد ذلك ، أو ترتيب / فعل / تأكيد ، أو حتى (المرحلة الأربعة الأولى تذهب هنا) .

يمكنك قراءة المزيد حول هذا الموضوع في قسم "اختبارات بسيطة مع أكثر من ثلاثة أسطر من التعليمات البرمجية" هنا .

أنا لا أحب بشدة استخدام الأسطر الفارغة بدلاً من التعليقات في OSS وأعارض فكرة Marks هذه. انظر تعليقي هنا .

التعليقات الموجودة أعلى كل مرحلة اختبار هي ، في الأساس ، تعليقات . وفي هذه الحالة بالذات ، فهم يعتذرون ، لأنهم يشرحون كيف - وليس لماذا .

الآن ، عد إلى AutoFixture ، نظرًا لأن جميع الاختبارات مزينة بالتعليقات ، وبما أن مرحلة تفكيك التركيبات فارغة في جميع الأوقات تقريبًا ، يمكننا المضي قدمًا وتغييرها إلى AAA .

وفي هذه الحالة بالذات ، هم اعتذار

حسنًا ، أنا أيضًا أشير إلى هذه القاعدة كثيرًا ، ولكن في هذه الحالة بالذات أفضل إبقاء هؤلاء "يعتذرون" 😄 يجعلون هيكل الاختبار أكثر وضوحًا وصرامة. أنا شخصياً أجد أنه من الأسهل قراءة الاختبارات "المصنفة" ، ولكن من المحتمل أن تكون هذه مجرد مسألة عادة 😉

ولكن ربما يكون هذا مجرد مسألة عادة

هذه؛ وربما أيضًا مسألة من كتب الاختبار بالفعل.

مرحبًا ، أود معالجة هذا الأمر. أنا من أشد المعجبين بـ Autofixture وأستخدمه في عملي طوال الوقت وستكون طريقة جيدة لرد الجميل.
لذلك ، تريدون بشكل أساسي تغيير ما يلي في جميع ملفات الاختبار:
// Fixture setup إلى // Arrange
// Exercise System إلى // Act
// Verify Outcome إلى // Assert
وأخيرًا // Teardown شيء.

نعم ، ولكن ضع في اعتبارك أن إجراء "بحث واستبدال" قد لا يعمل حيث يتم ضم بعض المراحل معًا في بعض الاختبارات. أي ، قد تصادف نظام التمرين والتحقق من النتائج وما شابه ، IIRC.

moodmosaic أنا أفهم ، أخطط لعمل ملف تلو الآخر ليس "

شكرا لك،
عيسى

moodmosaic مقابل // Exercise system and verify outcome يجب استبداله بـ
// Act and Assert
أو أنتم تفكرون في شيء مختلف يا رفاق؟

عادةً ما أستخدم // Act & Assert لأنه يبدو أكثر إيجازًا ورائعًا 😎 ما لم يكن لدى moodmosaic مخاوف ، أفضل اتباع هذا النمط 😉

في كلتا الحالتين على ما يرام:

لذلك أحاول البدء في هذا وبعد أن أقوم بتحميل All.sln في VS 2017 مشروعي F #
فشل (AutoFoq و AutoFoqUnitTest) في الفتح. لدي خبرة zeor مع F # لذا فإن أي مساعدة ستكون محل تقدير

micheleissa تأكد من استخدام أحدث إصدار من VS (15.5.1 أو أحدث) ، وإلا فلن يفتح المشروع (MS تطبيق التغييرات على F # SDK الخاصة بهم). تأكد أيضًا من تشغيل git clean -fdx . في الجذر مع إغلاق VS. هذا هو تنظيف الملفات المؤقتة في حالة قيامك بسحب المشروع مسبقًا.

كلتا الخطوتين يجب أن تساعد. اسمحوا لي أن أعرف إذا لم يفعلوا 😉

zvirja لقد قمت بالترقية إلى أحدث إصدار من VS 2017 15.5.2 وما زلت أواجه نفس المشكلة 😞

هل جربت الجزء الثاني؟

• إغلاق VS
• تحقق من أحدث master
• انتقل إلى الجذر وقم بتشغيل git clean -fdx .
• فتح VS مرة أخرى؟

يبدو أن لديك بقايا من SDK السابقة.

تأكد أيضًا من تثبيت أدوات F # على جهازك:

نعم ، لقد نسيت الثانية آسف :)
سأحاول ذلك الآن

zvirja التي عملت ، شكرًا جزيلاً للمساعدة!

سؤال آخر ، كيف يمكنني ربط الفرع الذي أعمل عليه في الريبو المتشعب الخاص بي بهذه التذكرة؟

رائع أنه نجح! 👍

كيف أقوم بربط الفرع الذي أعمل عليه في الريبو المتشعب الخاص بي بهذه التذكرة؟

أقترح إلقاء نظرة على هذه المقالة ، يتم وصف سير العمل جيدًا هناك: https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/Development-workflow-with-Git : -Fork ، -Branching ، - يلتزم وسحب الطلب

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

حسنًا ، حسنًا. شكرا لك! سأقوم بإنشاء طلب السحب أثناء عملي على المشكلة حتى تتمكنوا يا رفاق من مراقبة التقدم وتقديم الملاحظات وفقًا لما هو مذكور في إرشادات المساهمة.