Nunit: فشل اختبار AssertionException في الاختبارات منذ 3.10.

يختبر اختبارك اقتراحين حول كيفية عمل NUnit:

1. تؤدي جميع حالات فشل التأكيد إلى AssertionException.
2. يؤدي اصطياد الاستثناء إلى منع الإبلاغ عن الخطأ.

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

أدرك أن الغرض من نموذج التعليمات البرمجية هو توضيح المشكلة التي تراها فقط. هل يمكنك تقديم مثال لما تحاول فعله بالفعل في اكتشاف الاستثناء؟ أنا متأكد من أنه يمكننا مساعدتك في إيجاد حل أفضل.

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

لقد حاولنا استخدام طريقة Warn.If () لهذا الغرض ، ولكن هذا يضبط النتيجة على "تم تخطي الاختبار" في مستكشف الاختبار. يؤدي هذا إلى الإبلاغ عن حالات الفشل حيث لا يتم تخطي الاختبار على الإطلاق. لذلك اخترنا تنفيذ ميزة التقاط التأكيد بدلاً من ذلك وتتبع التحذير. أعلم ، غير مرغوب فيه ولكنه نجح بشكل جيد. على الأقل حتى آخر تحديث.

لدي فضول لمعرفة ما إذا كان هذا التغيير متعمدًا ، وفي هذه الحالة أعلم أنه يجب علي تغيير الأشياء.

Warn.If يعمل بشكل جيد ... __ باستثناء__ ضمن Test Explorer. 😢 تكمن المشكلة في أن Test Explorer يعرف أمر النجاح والفشل ، ولكن ليس التحذير. كان علينا ترجمة نتائج التحذير الخاصة بنا إلى شيء يمكنهم فهمه حتى يحين الوقت الذي يقومون فيه بتنفيذ حالة نتيجة التحذير. FWIW لدينا مشكلة مماثلة مع حالة النتيجة غير الحاسمة.

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

إذا كانت لديك اختبارات غير مستقرة ، فإن المعيار لسنوات عديدة هو تجاهلها. لسوء الحظ ، فإن العديد من الفرق "تتجاهل الاختبارات التي تم تجاهلها" ، وفي هذه الحالة لا يكون هذا اختيارًا جيدًا. إذا كان بإمكانك تدريب فريقك على أخذ التحذيرات على محمل الجد - تقريبًا بجدية الأخطاء والفشل - فيمكنك استخدام حالة التحذير لإبراز التقلبات. الاحتمال الآخر هو استخدام Ignore مع خاصية until ، لذلك يتحول إلى فشل إذا لم يتم إصلاحه بحلول تاريخ معين.

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

svanimpelen هل حاولت استخدام السمة Retry لاختباراتك غير المستقرة؟ سيسمح لك بتشغيلها عدة مرات لتمريرها.

بالنسبة للتحذير الذي أدى إلى تخطي الاختبارات في المستكشف ، فقد تحدثنا إلى فريق الاستوديو المرئي حول السماح لنا بتحديد حالات نتائج أكثر من العدد المحدود من MSTest الذي يدعمونه حاليًا. لقد أحبوا الفكرة ، لذلك نأمل أن نرى تحسينات هناك في المستقبل. حتى ذلك الحين سوف تحتاج إلى أن تعاني من التخطي. ومع ذلك ، تم تخطي النتائج في التحذيرات. أفترض أنك أردت أن تكون التحذيرات واضحة جدًا 😄

توثق العديد من أساليبنا أن واجهة برمجة التطبيقات ترمي AssertionException عند الفشل:

https://github.com/nunit/nunit/blob/d03e93c8f25170a8ff48e80863a3fe6fd294613a/src/NUnitFramework/framework/Assert.That.cs#L40 -L43

ألا تشكل هذه الوثائق ، بالإضافة إلى السلوك الطويل الأمد لـ NUnit ، تغييرًا فاصلًا في 3.10؟
ما لم أفقد شيئًا ما ، يجب علينا على الأقل إزالة المستندات غير الصحيحة الآن.

أوافق على أن الوثائق يمكن أن تكون مضللة الآن بعد أن قدمنا ​​مجموعات تأكيد متعددة. ومع ذلك ، لا يزال يتم طرح AssertionException في هذه الحالة ، والفرق هو أنه يتم الآن الإبلاغ عن الاختبار على أنه فشل في Visual Studio على الرغم من اكتشاف الاستثناء. لا أرى في ذلك تغييرًا جذريًا. كان المستخدمون يعتمدون على سلوك غير موثق حدث للعمل. بالنسبة لي ، لا يختلف ذلك عن اعتماد المستخدمين على حقيقة أن الاختبارات جرت بترتيب أبجدي لطلب اختباراتهم.

ربما ينبغي علينا تحديث الوثائق. يمكننا إزالة المعلومات حول طرح استثناء وبدلاً من ذلك نذكر فقط أن الشرط الخاطئ يفشل في الاختبار. و / أو ، يمكننا أن نقول أن الاستثناء لا يتم طرحه في كتل متعددة التأكيدات؟ أنا شخصياً أعتقد أن نوع الاستثناء الذي يتم طرحه هو تفاصيل داخلية ، لذلك أفضل الخيار الأول.

أعتقد أن ذلك صحيح . إذا كان سيتم توثيق استخدام الاستثناءات في أي مكان ، فيمكن أن يكون في قسم wiki الخاص بالأجزاء الداخلية.

عندما تشير وثائق الطريقة إلى أنه سيتم طرح استثناء ، أعتقد أنه لا لبس فيه أن الاستثناء يمكن اكتشافه في موقع الاتصال. لم تتحقق C # من الاستثناءات ومستندات XML هي الطريقة التي كنا نتواصل بها مع هذا الجزء من عقد الطريقة. نظرًا لأنني على حد علمي فإن اللغة "رميات X" تعني دائمًا أن الطريقة لا تلتقطها ، ما زلت قلقة بعض الشيء من هذه الطريقة التي أخذها الآخرون. ربما ملاحظة تغيير كسر في الويكي لتكون في الجانب الآمن؟

تعجبني فكرة إزالة جميع الإشارات إلى AssertionException من مستندات XML وإنشاء صفحة wiki تحذر الأشخاص من استخدام AssertionException.

💭إذا كان اصطياد AssertionException دائمًا خطأ ، فهل يمكننا التفكير في جعل هذا النوع داخليًا؟

@ jnm2.

أتفق معك بشأن أهمية مستندات XML ولكن الحقيقة هي أن هذه المستندات __لا _ هي الطريقة التي نتواصل بها مع جزء من العقد حتى الآن. أعتقد أنك قد تكون أول شخص يقترحها وأعتقد أنها فكرة جيدة.

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

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

إليكم كيف أرى الاختلاف - قد يختلف الآخرون ... توثيق __ كل شيء قد ينكسر _ يشم رائحة مثل CYA بالنسبة لي ، مثل نوع CYA الذي تنغمس فيه الإدارة أحيانًا عندما تركز على من يتم إلقاء اللوم عليه بسبب الفشل بدلاً من منع الفشل نفسه. إذا قمنا بتوثيق كل شيء ، فيمكننا القول ... "انظر ، نحن مغطى." إذا قمنا بتوثيق ما نراه مهمًا فقط ، فإننا نخاطر بأن نكون مخطئين ونضطر إلى الاعتذار ، لكننا نمنح المستخدم العادي قدرًا أكبر من السهولة في فهم مجموعة التغييرات. أنا أفضل هذا الأخير.

هناك أوقات يكون فيها من الآمن التقاط استثناء تأكيد. على سبيل المثال ، قمت بإجراء تغيير منذ فترة حتى يظل آمنًا عند إجراء الاختبارات مباشرةً ، دون تضمين TestExecutionContext. إذا جعلت الاستثناء داخليًا ، فإنك تكسر ذلك. في الواقع ، كنت سعيدًا لكسرها ، لكن الفريق وافق على أنه لا ينبغي لنا ذلك ، لذا قمت بإصلاحه. عليك فقط أن تقرر ما الذي ترغب في كسره. هذا الإصلاح __لا _ يعالج المشكلة الحالية ، التي تتعامل مع التقاط الاستثناء داخل الاختبار نفسه ، وليس في الكود الذي يستدعي الطريقة.

اصطياد AssertionException في الاختبار هو ما يمكن أن أسميه "الرائحة" الكلاسيكية. ربما يكون هذا خطأ ، لكن عليك أن تنظر إلى الحالة المحددة لتعرف. أود أن أخبر المستخدمين "من المرجح أن يكون Catching AssertionException خطأً ، إلا إذا كانت لديك معرفة تفصيلية بأجزاء NUnit الداخلية. لضمان السلوك السليم ، يجب ألا تحاول تغيير نتيجة الاختبار ويجب أن تعيد طرح الاستثناء بعد القيام بما تريد القيام به معها ". ومع ذلك ، ما زلت لا أعتقد أن هذه المعلومات تنتمي إلى مستندات XML أو مستندات المستخدم العامة. كنت أضعها كصفحة في قسم الداخلية.

راجع للشغل ، تجربتي السابقة كانت أن توثيق شيء ما ثم إخبار الناس بعدم استخدامه يؤدي إلى زيادة الاستخدام. 😄

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

هل يجب أن نبدأ إصدارًا جديدًا لتتبع إصلاح المستندات؟

لماذا الجديد؟

يبدو العنوان وكأنه شيء أغلقناه كسؤال تمت الإجابة عليه بدلاً من إصلاحه. هل نغير العنوان عادةً ونستخدم هذه المشكلة لتتبع تغيير المستند؟

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

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

هل يمكنك تقديم مثال لما تحاول فعله بالفعل في اكتشاف الاستثناء؟ أنا متأكد من أنه يمكننا مساعدتك في إيجاد حل أفضل.

أواجه حاليًا نفس المشكلة منذ أن بدأت اختباراتي بالفشل بعد الترقية إلى 3.10. الآن هذه هي مشكلتي:
لدي طرق اختبار مخصصة لتأكيد الاختبار. تلك المكالمات الداخلية NUnit.Assert. أختبر طرق التأكيد هذه للتأكد من أنها تفشل بالفعل عندما أتوقع فشلها.
في الوقت الحالي ، تلتقط اختباراتي AssertionException للتحقق من أن طريقة التأكيد المخصصة ستؤدي إلى فشل الاختبار ، ولكن بعد ترقية جميع هذه الاختبارات تبدأ بالفشل للأسباب المذكورة أعلاه.

ما هي الطريقة الموصى بها لاختبار 3.10؟

شكرا.

إن أبسط طريقة هي استخدام Assert. يحرص على التقاط الاستثناء بدلاً من القيام بذلك بنفسك. Assert.Trows يفهم العناصر الداخلية لـ NUnit ويضمن عدم الإبلاغ عن الفشل.

رأيت هذا في إشعاراتي في اليوم الآخر ولم أفكر كثيرًا في ذلك. ومع ذلك ، فإن تحديث مشروع مكتبة خاص بي ، والذي يقوم بـ "تأكيد ذلك" ضمن منطقه (إنه إطار عمل مساعد للاختبار - تحديدًا لتوفير طريقة سهلة لاختبار استمرارية EF عند ترميز سياقات وكيانات EF يدويًا وترميز قاعدة البيانات المقابلة عمليات الترحيل يدويًا (أو بشيء مثل FluentMigrator) - لذلك ، بعبارة أخرى ، من المفترض أن تؤدي تأكيدات نيابة عن المتصل) ، أحصل الآن على اختبارات فاشلة حيث لا ينبغي أن تكون - الاختبار الوحيد على وجه الخصوص هو التأكيد أن شرطًا معينًا يجب أن يؤدي إلى إخفاقات الاختبار - وهو ما يحدث ، ولكن نظرًا لأن "الصيد" لم يعد يعمل كما هو دائمًا ، يتم الإبلاغ عن هذه الاختبارات ، أثناء اجتيازها فعليًا ، على أنها فاشلة.

لذا أعتقد أنه لا يمكنني تقديم تأكيدات NUnit المناسبة ، أو استخدام Assert.That في رمز المكتبة الذي يهدف إلى المساعدة في تطوير الاختبار بشكل أسرع من خلال أداء مهام مملة للمستخدم؟

أوافق على العبارات السابقة بأنه إذا لم يستطع المستخدم استخدام الاستثناء ، فلا ينبغي أن يكون متاحًا للمستخدم ؛ ومع ذلك ، فإن هذا لا يحل المشكلة حيث لديّ رمز Assert.That في مكانه للمستهلك واختبارات لإثبات أنهم يرمون الفشل لأن الكود يفعل ما يفترض به: الفشل مع تأكيدات nunit.

ربما ينبغي علينا إنتاج بعض واجهات برمجة التطبيقات الناتجة؟

fluffynuts إذا كنت catch موجودة في كود الاختبار الخاص بك ، وليس كود مكتبة المستخدم الخاصة بك. (إذا كان موجودًا أيضًا في مكتبة المستخدم ، فيمكننا التحدث عن ذلك ، لكن المشكلات مختلفة قليلاً.)

بالطبع ، لدى NUnit اختبارات خاصة بها ، لذلك كانت لدينا نفس المشكلة المحتملة تمامًا عندما تم إجراء هذا التغيير. بطبيعة الحال ، قمنا بتعديل اختباراتنا الخاصة بحيث استمرت في النجاح. تستطيع فعل مثل الشيء.

خط الدفاع الأول هو Assert.Throws . في معظم حالات اختبار سلوك الفشل ، يمكنك استبدال try / catch(AssertionException) بـ Assert.Throws<AssertionException> مباشرة. داخليًا ، ينشئ Assert.Throws طردًا معزولًا TestExecutionContext حتى لا تتلوث نتائج اختبارك الفعلية بالخطأ الذي تختبره.

في حالات قليلة ، قد تحتاج إلى إنشاء سياق منعزل خاص بك. يمكنك معرفة كيفية القيام بذلك عن طريق فحص رمز Assert.Throws .

ومع ذلك ، فإن الكثير من اختبارات الفشل الخاصة بـ NUnit تستخدم بالفعل نهجًا مختلفًا. لدينا مجموعة منفصلة مع الاختبارات التي يتم تشغيلها بواسطة برامج الاختبار الخاصة بنا. نلتقط النتيجة ويمكننا بعد ذلك فحصها. هذا مزيد من العمل ولكنه يتجنب وضع الكثير من تفاصيل التنفيذ حول NUnit في اختباراتنا. تم العثور على معظم الطرق التي تقوم بذلك في مجموعة أدوات الاختبار الخاصة بنا. أعتقد أن هذا ما يشير إليه @ jnm2 .

انشر أي أسئلة لديك أو اتصل بي في وضع عدم الاتصال للحصول على مزيد من المساعدة في هذا الشأن.

شكرا للمعلومة. نعم ، التأكيدات محصورة في كود الاختبار. عادةً ما تقوم Assert.Throws بالخدعة ، لكن الاختبار المحدد المعني يقوم بتشغيل رمز المكتبة باستخدام دلتا "منخفضة جدًا" مسموح بها لاختبار قيمة التاريخ والوقت التي يجب وضعها فيها واستردادها من قاعدة بيانات. في معظم الأوقات ، يكون الانجراف الذي حدث لهذا في localdb هو 1 مللي ثانية ، ولكن في بعض الأحيان ينجرف إلى أعلى - ويهدف هذا الاختبار فقط إلى التأكيد على حدوث "أحيانًا". لذلك ، في الوقت الحالي ، أقوم بتشغيل الكود في 4 سلاسل متوازية ، 10 مرات وأتوقع فشلًا واحدًا على الأقل. تأكيد: العروش ، للأسف ، حتمية للغاية بالنسبة لهذه الحالة ، لذلك أنا بحاجة إما إلى التوقف عن استخدام استثناءات nunit (أو التأكيد ، ضمن كود المكتبة) ، أو أحتاج إلى تعلم fu الذي تستخدمه يا رفاق. أقدر أي مؤشرات - يمكن أن تحدث في وضع عدم الاتصال ، إذا كنت ترغب في ذلك.

هيه ، لقد أدركت للتو أن إخفاقات اختبار مضخة الرسائل الخاصة بي AsyncVoidVerificationScope التي كنت أحدق فيها هي بالضبط نفس المشكلة التي تواجههاfluffynuts . في الواقع بسبب ترقية NUnit 3.10 ، وليس [التجميع: RestoreSynchronizationContext] ITestAction. يخدمني بشكل صحيح لتجاهلهم أثناء القيام بأشياء متعددة في وقت واحد. :د

على أي حال ، يبدو أن ما أريد القيام به هو التفاف استدعاء المندوب الخاص بي في using (new TestExecutionContext.IsolatedContext()) تمامًا كما يفعل Assert.Throws .

Assert.Throws و Assert.ThrowsAsync بتأسيس سياقات معزولة قبل استدعاء المفوضين غير المتزامنين بالرغم من ذلك. لماذا هذا؟

fluffynuts منذ وقت طويل ، عندما كتبت Assert.Catch لأول مرة ، اكتشفت أي استثناء ولم تظهر أي خطأ إذا لم يتم طرح أي استثناء. لسوء الحظ ، تغير ذلك ولم يعد لدينا ما يعادل Assert.Throws "محايد". ومع ذلك ، يمكنك كتابة واحدة. هذه نسخة لم يتم اختبارها بناءً على الكود الموجود في Assert.Throws . إنه يتعامل فقط مع التعليمات البرمجية المتزامنة ولكن يمكنك توسيعها بسهولة للتزامن باستخدام رمز إضافي من Assert.Throws .

ج #
استثناء الفراغ العام الثابت SafelyCatchAnNUnitException (رمز TestDelegate)
{
تم الاستثناء من الاستثناء = null؛

using (new TestExecutionContext.IsolatedContext())
{
    try
    {
        code();
    }
    catch (Exception ex)
    {
        caughtException = ex;
    }

    return caughtException;
}

}
""

ستعيد الطريقة أي استثناء يتم طرحه ، وتنظيف أي بقايا من الخطأ خلفتها طرق التأكيد الخاصة بـ NUnit. إذا لم يتم طرح أي استثناء ، فسيتم إرجاعه فارغًا.

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