Nunit: قم بتشغيل طرق الاختبار داخل تركيبات بالتوازي

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

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

هذا يصبح مملًا بعض الشيء. تم ذكر بعض النقاط بالفعل ولكن يبدو أنها فاتتها ...

1. هناك خطة لتنفيذ ما تطلبه.
2. قررنا كفريق جدولة ذلك في وقت معين.
3. عندما يتم جدولتها ، يتعلق الأمر في المقام الأول بتقييمنا لقيمة الميزة مقارنة بالميزات الأخرى.
4. هناك العديد من الأشخاص في فريق NUnit الذين يمكنهم تنفيذ الميزة.
5. سيكونون قادرين على تنفيذه ، حسب الأولويات ، من رؤوسهم ولن يحتاجوا إلى نسخه من أي مكان.

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

بينما ساهمت بالعديد من التصحيحات في MbUnit واستخدمتها لسنوات ، كنت كذلك
أبدا مساهم رئيسي. لا أريد أن يتم تحريف وضعي :)

بالنسبة للهندسة العكسية ، لا يوجد أي استخدام هنا. يعمل NUnit
مختلفة تمامًا عما فعلته MbUnit. سنصل إلى هذه المشكلة في الوقت المناسب ،
لكننا نتعامل معها بحذر لأن مشكلات أخرى مماثلة قد تتغير
الطريقة التي نحتاجها لتنفيذ هذا أو حتى الصراع.
في 19 نيسان (أبريل) 2015 ، الساعة 2:45 صباحًا ، كتب "CharliePoole" [email protected] :

هذا يصبح مملًا بعض الشيء. بعض النقاط التي سبق ذكرها ولكن
غاب على ما يبدو ...

1.

هناك خطة لتنفيذ ما تطلبه.
2.

قررنا كفريق جدولة ذلك في وقت معين.
3.

عندما يتم جدولة الأمر يتعلق في المقام الأول بتقييمنا لـ
قيمة الميزة مقارنة بالميزات الأخرى.
4.

هناك العديد من الأشخاص في فريق NUnit الذين يمكنهم تنفيذ
خاصية.
5.

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

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/nunit/nunit/issues/164#issuecomment -94244650.

تعليق لبقا أكثر بكثير من تعليقي!

أولوياتنا الحالية في عالم التنفيذ الموازي هي:

1. تنفيذ العملية المتوازية
2. مجموعات الاستبعاد
3. الطريقة المتوازية (في تركيبات واحدة) التنفيذ.

يبدو أن هذا يمثل الترتيب الأكثر فائدة للمستخدمين.

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

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

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

أهلا!
ستكون إضافة هذه الميزة إلى الإصدار التالي من NUnit أمرًا رائعًا ، لأنه الشيء الوحيد الذي يمنعني من التبديل إلى NUnit. هل ما زالت هذه الميزة مخططة لـ 3.4؟

julianhaslinger NUnit 3.4 سيتم

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

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

julianhaslinger لن يكون هذا طرحه في غضون أسبوع واحد فقط ، ولكن أود أن أراه قريبًا ، لذا فإن تصويتك يساعد: +1:

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

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

rprouse أنا أستخدم MbUnit / Gallio الآن. مات المشروع إلى حد كبير والآن سأنتقل إلى NUnit.

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

CharliePoole بالضبط ، مشكلتنا الفعلية هي وقت تشغيل حالات الاختبار. نود استخدام NUnit لاختباراتنا / الانحدار المؤتمتة (بما في ذلك Selenium / WebDriver) وبما أن بعض فصول الاختبار لدينا بها أكثر من 200 حالة اختبار ، فمن الصعب حاليًا تنفيذ مجموعة الاختبار بالكامل باستخدام NUnit.

أظهرت المقارنات (ضمن مجموعة اختبار أصغر من اختبارات الانحدار) أنه سيتم تنفيذ حل NUnit محتمل في حوالي 1.5 ساعة بينما سيتم تنفيذ حل MBunit الحالي في 0.5 ساعة (نفس مجموعة الاختبار).

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

julianhaslinger - فقط للتأكيد ، هل أنت متأكد من أنك تشغل وقتًا مرتبطًا بوحدة المعالجة المركزية ، وليس مقيدة بالذاكرة؟

لقد واجهنا نفس المشكلة عندما حاولنا لأول مرة التبديل إلى NUnit 3 - أصبح وقت التشغيل أطول بشكل ملحوظ. كان هذا بسبب قيام NUnit بتوسيع الذاكرة المتاحة إلى الحد الأقصى - ولكن هناك مشكلة في الإصدار الحالي الذي يحتفظ بجميع كائنات الاختبار حتى يكتمل تشغيل الاختبار. نقوم حاليًا بتشغيل إصدار مصحح داخليًا - أردت الحصول على PR في 3.4 ، لكن لست متأكدًا من أنه سيكون لدي وقت في هذه المرحلة. :-(

أعتذر إذا لم يكن الأمر كذلك ، لكن أعتقد أنه يستحق الذكر ، حيث يمكن للسيلينيوم استخدام نصيبه العادل من الذاكرة. :-)

ChrisMaddock شكرا على المدخلات! : +1: سنلقي نظرة عليه قريبًا وسأعود إليك بعد ذلك.

ChrisMaddock أحب أن أرى إصلاح ذاكرتك في 3.4. إذا كنت تريد طرح إعلان عام ، فيمكننا مساعدتك في تنظيفه إذا لم يكن جاهزًا للإنتاج بعد: +1:

rprouse - هذا الالتزام الأولي https://github.com/nunit/nunit/pull/1367/commits/5f98ae51025f7af8244abd4367d1f47260874dfc في PR # 1367 يحرر الأشياء بشكل صحيح بالنسبة لنا ، في إصدار مصحح 3.0.1.

ستلاحظ في PR أنه تم نقله إلى OneTimeTearDown قبل الدمج - لا أعرف حتى الآن ما إذا كانت هذه الخطوة قد تسببت في عدم العمل في الإصدار 3.2.1 ، أو إذا كان هناك تغيير آخر يعمل والذي أعاد تقديم الاحتفاظ - ربما لم أقم بإعادة الاختبار بعد الانتقال.

سنحاول إعادة اختباره وإلقاءه غدًا ، سيكون من الرائع بالنسبة لنا العودة إلى الإصدارات الأساسية أيضًا. :-)

ChrisMaddock لقد

فقط لإضافة ما قاله julianhaslinger ، لقد رأيت نفس المشكلة بالضبط في استخدام NUnit مع اختبارات السيلينيوم. اضطررت إلى كتابة غلاف مخصص يقوم بتشغيل مثيلات فردية من nunit-console.exe مقابل اختبار واحد كما تم مسحه من تجميع تم تمريره حتى أتمكن من إجراء اختبارات متوازية في الوقت الحالي. هذا ليس مثاليًا لأنه ينتج عنه العديد من ملفات الإخراج .xml التي يتم إنشاؤها (واحد لكل تشغيل اختباري) بدلاً من إخراج .xml واحد وهذا يعني أيضًا أنه لا يمكنني استخدام أساليب _OneTimeSetUp_ و teardown وبدلاً من ذلك يجب الاعتماد على إشارات خارجية ومتغيرات البيئة للتحكم في تدفق التنفيذ حيث أريد تشغيل الأشياء مرة واحدة فقط. لقد كنت أتبع الوعد بإجراء تنفيذ متوازي في NUnit لفترة طويلة الآن (سنوات) وشعرت بخيبة أمل كبيرة بشأن كيفية طرح الميزة في 3.0 (مدعومة جزئيًا فقط وتتطلب بعض البحث الحقيقي في المشكلات وإصدار الملاحظات إلى اكتشف أنه لم يكن كل شيء مدعومًا بالفعل). لقد ذهبت إلى أبعد من ذلك للتحقيق في ما يمكن أن ينطوي عليه المضي قدمًا بنفسي ، ولكن لسوء الحظ يبدو أن تصميم NUnit يعمل ضد تنفيذ التنفيذ الموازي على مستوى طريقة الاختبار ، وليس لدي أي فكرة عما تريده بالفعل للتعامل مع احتمال وجود رمز غير آمن للخيوط (على سبيل المثال ، يجب تركه للشخص الذي يستخدم NUnit بالتوازي للتأكد من أن جميع طرق الاختبار تشير بشكل صحيح إلى أي عناصر خارجية بطريقة آمنة أو يجب أن تتعامل NUnit نفسها مع تنفيذ كل طريقة في المجال الخاص بها بطريقة أو بأخرى أحاول الاستمرار فقط في تشغيل طريقتين للإعداد والتفكيك لمرة واحدة فقط) وبما أن لدي بالفعل حلًا بديلًا في مكانه ، لم أتمكن من تبرير الوقت في تنفيذ هذه الميزة بنفسي (وهو على الأرجح الأفضل لأنني كنت محترقًا من قبل عندما العمل مع الفرق على GitHub لمساعدتهم على تنفيذ التنفيذ المتوازي). على أي حال ... آسف للتجول ... أتفهم أن أولوية اختبار الوحدة لرمز C # ربما لا تعتمد على التوازي على مستوى الطريقة بنفس القدر ، ولكن يرجى معرفة ذلك بالنسبة لأولئك منا الذين يستخدمون NUnit للاختبارات القائمة على السيلينيوم سيكون تحسنا هائلا. شكرا لك مقدما! :ابتسامة:

شكرا لتعليقاتكم. أعتقد أنني سأتجول قليلاً هنا ...

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

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

فيما يتعلق بسلامة الخيوط - لم نخطط مطلقًا لتنفيذنا الموازي لتحمل مسؤولية سلامة الخيط. الشيء الوحيد الذي كنت أتوقع أن أضمنه هو أن NUnit لن تخلق أي مشاكل تتعلق بسلامة الخيط إذا كانت طرقك آمنة بالفعل. هذا في حد ذاته تبين أنه غير تافه.

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

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

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

آمل أن يساعد هذا في التوضيح ... آسف إذا كانت الأمور لا تزال غير واضحة تمامًا ،
لكن النقطة الإجمالية هي أن التوازي على مستوى الطريقة هو شيء لدي
شوهد في عداد المفقودين في مكتبات الاختبار الأخرى (prspec في الياقوت على سبيل المثال) ومتى
القيام بتحليل تحسينات الأداء التي سيتم إجراؤها عن طريق إضافتها ط
وجدت أنه يمكن أن يكون تغيير إيجابي كبير. انظر ما يلي كمثال:
https://github.com/bicarbon8/rspec-parallel/wiki/Examples
في 1 تموز (يوليو) 2016 00:45 ، كتب "CharliePoole" [email protected] :

شكرا لتعليقاتكم. أعتقد أنني سأتجول قليلاً هنا ...

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

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

فيما يتعلق بسلامة الخيوط - لم نخطط مطلقًا لتنفيذنا الموازي
لتحمل المسؤولية عن سلامة الخيط. الشيء الوحيد الذي كنت أتوقعه
الضمان هو أن NUnit لن _ تنشئ _ أي مشاكل متعلقة بسلامة الخيط إذا كان لديك
طرق خيط آمنة بالفعل. هذا في حد ذاته تبين أنه غير تافه.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/nunit/nunit/issues/164#issuecomment -229819324 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe/ACNsyoczCUV9L7kbF2SHB7lLsyBKlrv9ks5qRFUJgaJpZM4CUZ8r
.

شكرًا على المعلومات ... من المفيد رؤية مجموعة متنوعة من وجهات النظر.

5 سنتات بلدي.

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

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

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

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

تضمين التغريدة شكرا جزيلا!

في رأيي ، يجب عزل حالات الاختبار وعدم الاعتماد على حالات الاختبار الأخرى أو أمر التنفيذ. إذا كان الأشخاص لا يزالون يرغبون في إجراء بعض الاختبارات ذات الخيط الفردي ، فلا يزال بإمكانهم استخدام [Parallelizable (ParallelScope.None)] و / أو OrderAttribute.

ستسمح هذه المشكلة التي يتم تنفيذها بتشغيل مجموعات الاختبار بشكل أسرع مقابل شبكة Webdriver المحلية أو مزود Saas مثل BrowserStack أو SauceLabs. أحاول حاليًا تقييد عدد طرق الاختبار في فئة الاختبار على عدد عقد Webdriver المتاحة أو جلسات المتصفح ، لذلك يتم استخدام الشبكة بالكامل. خلاف ذلك ، إذا كان الاختبار يحتوي على 8 طرق اختبار وكانت شبكتي بها 8 جلسات متصفح متاحة ، فسيتم استخدام واحدة فقط لأن جميع طرق الاختبار للفصل ستعمل واحدة تلو الأخرى.

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

في حالة مواقع الويب ، لا نتحدث دائمًا عن اختبارات الوحدة. غالبًا ما تتطلب الاختبارات الوظيفية عالية المستوى التسلسل. سواء تم ذلك عبر مجموعة من الخطوات في الاختبار أو سلسلة من الأساليب ، فهي تفاصيل تنفيذية بالنسبة لنا ومسألة راحة للمستخدم. شخصياً ، أعتقد أننا ربما نحتاج إلى شيء يسمى [الخطوة] يقع داخل فئة [StepFixture] ، أو بعض الأسماء المماثلة ، حتى نتمكن من نقل كل عناصر الترتيب / التسلسل هذه بعيدًا عن اختبار الوحدة. ربما سيكون لدي الوقت للقيام بذلك قبل أن يموت الويب. :-)

على أي حال ، من المثير للاهتمام دائمًا معرفة كيفية استخدام الأشخاص لبرنامجك بالفعل.

CharliePoole ، من فضلك لا تفهموني بشكل خاطئ بسؤال هذا (أريد فقط أن أكون متأكدًا): هل ستتم إضافة هذه الميزة إلى الإصدار التالي (3.5 ، مستحق بحلول 29 سبتمبر 2016)؟

بينما يمكنني التظاهر بالتنبؤ بالمستقبل ، فإن ذلك لن يرضيك إلا حتى سبتمبر. :-)

اسمحوا لي أن أجيب من خلال شرح كيفية "جدولة" الميزات.

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

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

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

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

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

آسف ، لا توجد إجابة أكثر تحديدًا ولكن مثل هذه الإجابة ستكون بالضرورة كذبة!

CharliePoole ، هل هناك أي تحديث يتعلق بهذه الميزة؟

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

CharliePoole ، هل هناك أي تحديث لهذه المشكلة؟

KPKA لم نبدأ العمل على هذا بعد ، لذا لا يوجد تحديث. بالنسبة للمستخدمين الذين تم تثبيت ZenHub عليهم ، سترى هذه المشكلة تنتقل من Backlog إلى ToDo ثم قيد التقدم بينما نبدأ العمل عليها.

بالنسبة لغير مستخدمي Zenhub ، ستتمكن من معرفة متى يلتقطها شخص ما من خلال مشاهدة من تم تعيينه لهذه المشكلة.

تضمين التغريدة

أهلا!

هل هناك أخبار بخصوص هذا الموضوع؟
هل سيكون في الإصدار التالي أو إذا تم التخطيط له في أحد المعالم القادمة؟

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

اتمنى ان اسمع منك قريبا

GitSIPA ما هو إطار الاختبار الذي تستخدمه والذي يسمح لك بتشغيل طرق الاختبار بالتوازي؟

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

+1 ، أتفق معGitSIPA. هذه حقا وظيفة مهمة

GitSIPA +1
rprouse نحن نستخدم mbunit ، لكن إطار العمل هذا لا يدعم الآن. ولدينا بعض المشاكل مع mbunit.

rprouse نحن نستخدم أيضًا MbUnit في الوقت الحالي ، ولكن نظرًا لعدم تقديم الدعم لإصدارات Visual Studio الجديدة ، فقد فكرنا في التبديل إلى NUnit.

في الإصدار رقم 1921 @ jnm2 ، تم طرح السؤال "ما الذي يقف بيننا وبين تشغيل حالات الاختبار ذات المعلمات بشكل متوازٍ؟ هل يمكنني المساهمة؟"

السؤال الثاني أولا: بالتأكيد! نحن نحب مساعدتك.

وعن السؤال الأول:

1. نحن ننفذ "WorkItems" ، والتي تقوم حاليًا بتعيين واحد لواحد للاختبارات. أعتقد أننا بحاجة إلى التعامل مع OneTimeSetUp و OneTimeTearDown للتثبيت على أنهما WorkItems منفصلان كخطوة أولية. العدد 1096 يتناول هذا.

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

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

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

ما هو التخطيط الذي تم القيام به حتى الآن؟
احتياجاتي هي تشغيل عدد كافٍ من حالات TestCaseSource بالتوازي لإشباع وحدة المعالجة المركزية. ليس لدي أي متطلبات إعداد أو تفكيك أو طلب. سيحتاج الأشخاص الآخرون إلى أخذها في الاعتبار بالرغم من ذلك.

أتوقع أن يكون تنفيذ TestCaseSource متوازيًا ، لذا فإن طريقتين في نفس الأداة التي استخدمت TestCaseSources مختلفة ستنفذ التعداد بشكل متوازٍ. يبدو أيضًا أنه سيكون من الجيد إذا استخدمت طريقتان نفس TestCaseSource إذا تم تنفيذه مرة واحدة فقط - أفكار حول هذا؟

تحرير: التعليق RACE CONDITION. نحن في بداية جيدة بالفعل! 😆

سأكرر قصة كنت مضطرًا إلى روايتها كثيرًا مؤخرًا. :ابتسامة:

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

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

IOW ، حالات الاختبار الخاصة بك لا "تستخدم" مصدر الاختبار الخاص بك ، بدلاً من ذلك تستخدم NUnit المصدر لإنشاء حالات الاختبار. بالطبع ، لا يمكنهم فعل أي شيء حتى يتم إنشاؤه. منطقي؟

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

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

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

@ jnm2 هل

julianhaslinger لا. إنها مدرجة في قائمتي بعد مسألتين

julianhaslinger نظرًا لأننا لا نعرف بعضنا البعض ، يرجى المعذرة لقول إن هذا أمر صعب. تأكد من البحث في كيفية إنجاز الأشياء الآن ولماذا - هذا الأخير ليس واضحًا دائمًا أنا خائف. انظر تعليقي على https://github.com/nunit/nunit/issues/164#issuecomment -265267804 للتقسيم في العلاقات العامة المنفصلة التي أود رؤيتها لإصلاح ذلك. إذا توصلت إلى نهج أبسط ، فقم بنشره قبل ترميزه ، حتى نتمكن من موازنة الاعتبارات المستقبلية مقابل YAGNI الواضح الذي ينطوي على التنبؤ بالمستقبل.

تضمين التغريدة

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

CharliePoole كانت إحدى المشكلات المحتملة التي نفس مثيل Fixture ، مما يعني أنه إذا تم تنفيذ WorkItems بشكل متوازٍ ، فسيصلون إلى مثيل واحد من فئة الاختبار. هذا يمثل مشكلة بسبب ظروف السباق التي تنشأ عندما تعتمد الاختبارات على الإعداد أو Teardown لتعيين حقول مستوى المثيل.

يتمثل أحد الحلول لهذا الأمر في جعل كل WorkItem يعمل على مثيل جديد من فئة الاختبار ، ولكن من المحتمل أن يؤدي ذلك إلى تعقيد كيفية تصرف إعدادات Fixture لأنه لن يكون هناك مثيل واحد للتثبيت.

@ chris-smith-zocdoc نعم ، هذا هو أكبر فرق بين NUnit و junit السابقة. مرة أخرى في اليوم ، تمت مناقشته على نطاق واسع من المؤيدين والمعارضين ولكن لم يتم طرحه كثيرًا الآن. لهذا السبب ، كان من المفترض أن تكون اختبارات NUnit عديمة الحالة ، مع إجراء جميع عمليات التهيئة في طريقة SetUp.

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

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

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

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

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

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

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

عدني لذلك.

أنا أيضا!

يوم السبت ، 14 كانون الثاني (يناير) 2017 الساعة 3:58 صباحًا ، جوزيف موسير [email protected]
كتب:

>
>
>
>

[صورة: Boxbe] https://www.boxbe.com/overview

التنظيف التلقائي: احتفظ بآخر رسائل بريد إلكتروني واحدة ([email protected])

تحرير القاعدة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3Dwa43L7bW5j4V5ymh5QXh٪252FNXk٪252F0KVSSFJSqwHw2yu4No٪253D٪26token٪3DjkWoQ96YyOE٪252FHA7PvZA8g٪252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ٪252FKSZ2WZELsWD3YQoDEdjwb٪252BWo6wGi4xiUEkGngbggedv8iYBxU7zk٪ 252FJamyOuVtPzie4dhQJXQkQQ٪ 252BtolspNKBzqBxtH6H٪ 252FhqnTQ٪ 253D٪ 253D & tc_serial = 28420100882 & tc_rand = 128339648 & utm_source = stf email & utm_Omedium =

| حذف القاعدة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3Dwa43L7bW5j4V5ymh5QXh٪252FNXk٪252F0KVSSFJSqwHw2yu4No٪253D٪26token٪3DjkWoQ96YyOE٪252FHA7PvZA8g٪252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ٪252FKSZ2WZELsWD3YQoDEdjwb٪252BWo6wGi4xiUEkGngbggedv8iYBxU7zk٪ 252FJamyOuVtPzie4dhQJXQkQQ٪ 252BtolspNKBzqBxtH6H٪ 252FhqnTQ٪ 253D٪ 253D & tc_serial = 28420100882 & tc_rand = 128339648 & utm_source = stf email & utm_Omedium =

| ضع علامة كمهمة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3Dwa43L7bW5j4V5ymh5QXh٪252FNXk٪252F0KVSSFJSqwHw2yu4No٪253D٪26token٪3DjkWoQ96YyOE٪252FHA7PvZA8g٪252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ٪252FKSZ2WZELsWD3YQoDEdjwb٪252BWo6wGi4xiUEkGngbggedv8iYBxU7zk٪ 252FJamyOuVtPzie4dhQJXQkQQ٪ 252BtolspNKBzqBxtH6H٪ 252FhqnTQ٪ 253D٪ 253D٪ 26important٪ 3Dtrue٪ 26emlId٪ 3D54854949581 وtc_serial = 28420100882 & tc_rand = 128339648 & utm_source على = STF وutm_medium = البريد الإلكتروني والمتغير utm_campaign = ANNO_CLEANUP_EDIT وutm_content = 001

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

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

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

عدني لذلك.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-272488655 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAHNVlwVps8pQ93UIwZw6zY7TOyHO0a6ks5rR61EgaJpZM4CUZ8r
.

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

هذا هو الشيء: إذا كانت الطريقة غير قابلة للتوازي تمامًا ، فهذا يعني أنها لا يمكن أن تعمل بالتوازي مع __ أي طريقة أخرى__. OTOH ، إذا كانت غير قابلة للتوازي فقط داخل تركيباتها ، فلا يمكن تشغيلها بالتوازي مع __ أي طريقة أخرى في نفس المباراة .__

أقترح أن نتعامل مع هذا التمييز على النحو التالي:

1. إذا كانت طريقة الاختبار لا تحتوي على سمة Parallelizable ، فيجب تشغيلها على نفس مؤشر الترابط الذي يحتوي على تركيباتها ، بشرط عدم وجود أي سمة أخرى (مثل Apartment) تستدعي تشغيلها على مؤشر ترابط مختلف

2. إذا كانت تحتوي على سمة Parallelizable مع نطاق ذاتي ، أو إذا كانت مجموعة المستوى الأعلى تحدد نطاقًا للأطفال ، فسيتم تشغيل طريقة الاختبار بالتوازي مع الطرق الأخرى في الأداة.

أفكار @ نونيت / الفريق الأساسي؟

تركت أعلاه:

1. إذا كانت تحتوي على سمة Parallelizable بنطاق بلا ، فإنها تعمل في قائمة الانتظار غير المتوازية.

CharliePoole -

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

تتخذ PR # 2011 بعض الخطوات الأولية نحو تنفيذ هذه الميزة ولكنها تحتوي على #define الذي يفرض تشغيل حالات الاختبار على خيط التثبيت الخاص بها. يوثق هذا التعليق ما أعتقد أنه يجب القيام به لإزالة هذا القيد.

حاليًا ، يعمل OneTimeTearDown الخاص بالتثبيت على الخيط الذي تم استخدامه لإنهاء آخر حالة اختبار تم تنفيذها. إذا كانت حالات الاختبار تعمل بالتوازي ، فلا يمكننا التنبؤ بحالة الاختبار التي ستكون. قد يكون خيطًا بخصائص مختلفة عن تلك المطلوبة للتثبيت. على سبيل المثال ، إذا كان الاختبار الأخير الذي تم الانتهاء منه قيد التشغيل في STA ، فهذا ما سيتم استخدامه لتشغيل OneTimeTearDown ، حتى إذا تم تشغيل OneTimeSetUp في MTA. في كثير من الحالات ، قد لا يسبب ذلك أي مشكلة ولكن في بعض الحالات يمكن أن يسبب ذلك.

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

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

بالنسبة لأي شخص يتابع سلسلة الرسائل هذه منذ البداية (مرة أخرى في عام 2014) ولا يريد أو غير قادر على تنفيذ الحل البديل الخاص به أثناء انتظار إضافة هذه الميزة ، فقد عثرت للتو على تطبيق باستخدام NUnit 2.6.3 المتاح في يبدو أن CodePlex سهل الاستخدام للغاية (لقد تحققت من أنه يعمل في تشغيل اختباراتنا الوظيفية في سلاسل متوازية متعددة).

http://cpntr.codeplex.com/

نعتذر مقدمًا CharliePoole إذا كانت هذه الرسالة متعامدة قليلاً مع المناقشات الأخيرة حول هذا الموضوع ، ولكن إذا كان أي شخص آخر ينتظر السنوات الثلاث الماضية لإضافة هذه الميزة بناءً على الوعود التي تم تقديمها لـ NUnit 3 (طريق العودة في وقت مبكر أيام) ، أعتقد أنه قد يقدم حلاً حتى تتمكن يا رفاق من حل مشكلات التصميم (يبدو أنك تقترب من الحل).

تضمين التغريدة

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

هل نحتاج إلى أن يعرف المرسل عناصر التمزيق المعلقة مقدمًا ، أم يمكننا إرسالها عندما تصبح متاحة؟ بشكل ملموس ، حيث تستدعي CompositeWorkItem حاليًا PerformOneTimeTearDown ، هل يمكننا استخدام المرسل لإرسال وحدة عمل جديدة إلى وردية العمل الصحيحة؟

@ chris-smith-zocdoc نعم ، هذا بالضبط ما أفعله. لقد أنشأت نوعًا جديدًا من عنصر العمل ، OneTimeTearDownWorkItem ، وهو متداخل في CompositeWorkItem ويتم إرساله عند تشغيل آخر اختبار فرعي. لاحقًا ، قد ننظر إلى بعض الكفاءات عند تشغيل OneTimeSetUp وجميع الاختبارات على نفس السلسلة.

لم تقرأ كل شيء بعناية شديدة ، ولكن هناك شيء واحد أرغب في طلبه كجزء من هذه الميزة وهو أن يكون التوازي "ذكيًا" ، خاصة بالنسبة لاختبارات I / O المرتبطة. على سبيل المثال ، إذا كان لديك 10 خيوط تنفذ 100 اختبار متوازي ، فلا ينبغي أن تكون الحالة أن 10 خيوط تجلس وتنتظر حتى تكتمل الاختبارات العشرة الأولى قبل الانتقال إلى الاختبارات العشرة التالية. إذا بدأت الاختبارات العشرة الأولى في انتظار مهام الإدخال / الإخراج الطويلة جدًا ، فيجب أن تكون الخيوط حرة للانتقال إلى اختبارات أخرى. عند اكتمال مهام الإدخال / الإخراج ، ستستأنف سلاسل الرسائل الاختبارات المنتظرة مع تحرير سلاسل الرسائل.

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

@ chris-smith-zocdoc في الحقيقة ، هذا ما أفعله إلى حد كبير. أنا أستخدم بشكل أساسي آلية العد التنازلي الحالية لبدء إرسال مهمة تفكيك لمرة واحدة. الحيلة هي إرساله إلى قائمة الانتظار المناسبة.

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

هل يستطيع أحد أن يشرح لي كيف يعمل؟
لدي فصل اختبار
عندما أجري الاختبارات في هذا الفصل ليس بالتوازي - اجتازت جميع الاختبارات
لكن عندما أجريهم مع [Parallelizable (ParallelScope.Children)]
لذلك فهي تعمل بالتوازي (طرق متعددة في نفس الفئة)
ولكن لسبب ما فشلت بعض الاختبارات.
لدي حقول مثيل في هذه الفئة يتم استخدامها عبر الاختبارات ويبدو أن هذه الحقول مشتركة بين سلاسل الرسائل
هل انا على حق؟
هل تنشئ مثيلًا واحدًا فقط من تلك الفئة وتستدعي الأساليب بشكل متزامن على هذا الكائن الفردي؟
تشارليبول

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

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

من الممكن أن يكون لديك [Parallelizable (ParallelScope.Children)] في
ملف AssemblyInfo.cs؟

هل رأى أي شخص أن هذا يعمل؟

في 14 يونيو 2017 الساعة 01:37 ، كتب CharliePoole [email protected] :

[صورة: Boxbe] https://www.boxbe.com/overview Automatic Cleanup: keep
آخر رسالة بريد إلكتروني واحدة ([email protected]) عدّل القاعدة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk٪253D٪26token٪3D0PvYtf1G2B٪252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8٪252BJm73uy8ZNUCnQcknlgWKxRQ5zjE٪252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF٪252FW٪252BhysbMtsDw٪253D٪ 253D & tc_serial = 30872123699 & tc_rand = 2087335475 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| حذف القاعدة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk٪253D٪26token٪3D0PvYtf1G2B٪252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8٪252BJm73uy8ZNUCnQcknlgWKxRQ5zjE٪252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF٪252FW٪252BhysbMtsDw٪253D٪ 253D & tc_serial = 30872123699 & tc_rand = 2087335475 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| ضع علامة كمهمة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk٪253D٪26token٪3D0PvYtf1G2B٪252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8٪252BJm73uy8ZNUCnQcknlgWKxRQ5zjE٪252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF٪252FW٪252BhysbMtsDw٪253D٪ 253D٪ 26important٪ 3Dtrue٪ 26emlId٪ 3D61187554820 & tc_serial = 30872123699 & tc_rand = 2087335475 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001

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

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-308157832 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAHNVuK-J-X74mlAA_eT7OX7dxs7MpoRks5sDqzLgaJpZM4CUZ8r
.

agray نعم ، في الحقيقة هذا هو السبب الوحيد

مرحبا جوزيف ،

ما هو خط التوازي الذي تضيفه إلى ملف AssemblyInfo.cs الخاص بك؟

أود أن أعرف ما الذي يصلح.

هتافات،

أندرو

يوم الأربعاء ، 14 حزيران (يونيو) 2017 الساعة 4:17 مساءً ، جوزيف موسير [email protected]
كتب:

[صورة: Boxbe] https://www.boxbe.com/overview Automatic Cleanup: keep
آخر رسالة بريد إلكتروني واحدة ([email protected]) عدّل القاعدة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3DnRGYOf٪252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w٪253D٪26token٪3DDcwWzMT9yPtQLckdXD3BLhW5xAB٪252BMpc9XdsrbBlwdQJZC٪252Bjo3SjsyMVC8vese٪252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj٪252B2Cfcwg51yUFFQJSwrmTVxqAk4٪252BTVGDSrnutdAuqiJ3kTaYQA٪ 253D٪ 253D & tc_serial = 30882364582 & tc_rand = 1974513896 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| حذف القاعدة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3DnRGYOf٪252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w٪253D٪26token٪3DDcwWzMT9yPtQLckdXD3BLhW5xAB٪252BMpc9XdsrbBlwdQJZC٪252Bjo3SjsyMVC8vese٪252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj٪252B2Cfcwg51yUFFQJSwrmTVxqAk4٪252BTVGDSrnutdAuqiJ3kTaYQA٪ 253D٪ 253D & tc_serial = 30882364582 & tc_rand = 1974513896 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| ضع علامة كمهمة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3DnRGYOf٪252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w٪253D٪26token٪3DDcwWzMT9yPtQLckdXD3BLhW5xAB٪252BMpc9XdsrbBlwdQJZC٪252Bjo3SjsyMVC8vese٪252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj٪252B2Cfcwg51yUFFQJSwrmTVxqAk4٪252BTVGDSrnutdAuqiJ3kTaYQA٪ 253D٪ 253D٪ 26important٪ 3Dtrue٪ 26emlId٪ 3D61214070592 & tc_serial = 30882364582 & tc_rand = 1974513896 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = ANNO_CLEANUP_EDIT & utm_content =

array https://github.com/array نعم ، في الواقع هذا هو السبب الوحيد
لديك AssemblyInfo.cs الآن.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-308325726 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAHNVghNAX8CJkqAy-qhAz8bXNhZcFOQks5sD3NigaJpZM4CUZ8r
.

agray الذي سألت عنه:

c# [Parallelizable(ParallelScope.Children)]

لا تنسى الهدف

[assembly: Parallelizable(ParallelScope.Children)]

LirazShay أستخدم NUnit لقيادة اختبارات السيلينيوم ، وكنت أستخدم حقولًا على مستوى التجهيزات للاحتفاظ بأشياء مثل المراجع إلى حسابات المستخدمين وإلى مثيل Selenium WebDriver الذي كنت أعمل معه وبالتالي لم أتمكن من تشغيل الاختبارات بالتوازي في تركيبات. كانت الطريقة التي عملت بها حول ذلك هي كتابة "مصنع" (أستخدم علامات الاقتباس لأنني لست متأكدًا من أنه المصطلح الصحيح) الذي يطبق IDisposable الذي يلخص جميع احتياجات الاختبار الخاصة بي لكل اختبار ويمزقها تمامًا في نهاية اختبار دون الحاجة إلى [TearDown] أو [OneTimeTearDown] نوع من هذا القبيل:

 public class TestFactory : IDisposable
    {
    // Instantiate a new SafeHandle instance.
    private readonly System.Runtime.InteropServices.SafeHandle handle = new Microsoft.Win32.SafeHandles.SafeFileHandle(IntPtr.Zero, true);

    // Flag: Has Disposed been called?
    private bool disposed = false;

    public TestFactory()
    {
        this.UserRepository = new List<UserAccount>();
        this.DU = new DataUtility();
    }

    // A list of users created for this test
    public List<UserAccount> UserRepository { get; private set; }

    // A very simple data layer utility that uses Dapper to interact with the database in my application 
    public DataUtility DU { get; private set; }

    // Gets a new user and adds it to the repository
    public UserAccount GetNewUser()
    {
        var ua = new UserAccount();
        this.UserRepository.Add(ua);
        return ua;
    }


    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (this.disposed)
        {
            return;
        }

        if (disposing)
        {
            // Deletes all user accounts created during the test
            foreach (UserAccount ua in this.UserRepository)
            {
                try
                {
                    ua.Delete();
                }
                catch (Exception)
                {
                    // Take no action if delete fails.
                }
            }

            this.DU.DeleteNullLoginFailures(); // Cleans up the database after tests
            Thread.Sleep(1500);
        }

        this.disposed = true;
    }
}

بعد ذلك ، يمكنني القيام بذلك ضمن الاختبار:

[TestFixture]
public class UserConfigureTests
{
    [Test]
    public void MyExampleTest()
    {
        using (TestFactory tf = new TestFactory())
        {
            var testUser = tf.GetNewUser();

    tf.DU.DoSomethingInTheDatabase(myParameter);

    // Test actions go here, and when we exit this using block the TestFactory cleans
    // up after itself using the Dispose method which calls whatever cleanup logic you've written into it
        }
    }
}

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

tparikka أوصي بشدة بهذا النهج بنفسي.

لدي ما يلي في ملف AssemblyInfo الخاص بي:

[التجمع: Parallelizable (ParallelScope.Children)]
[التجميع: LevelOfParallelism (16)]

هل أحتاج إلى خاصية LevelOfParallelism أيضًا بعد الآن؟

في 15 يونيو 2017 الساعة 04:37 ، كتب جوزيف موسر [email protected] :

[صورة: Boxbe] https://www.boxbe.com/overview Automatic Cleanup: keep
آخر رسالة بريد إلكتروني واحدة ([email protected]) عدّل القاعدة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3Doth٪252FFbAPG٪252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ٪253D٪26token٪3DHe7HfTrm٪252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp٪252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy٪252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A٪253D٪ 253D & tc_serial = 30894750852 & tc_rand = 1847060911 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| حذف القاعدة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3Doth٪252FFbAPG٪252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ٪253D٪26token٪3DHe7HfTrm٪252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp٪252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy٪252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A٪253D٪ 253D & tc_serial = 30894750852 & tc_rand = 1847060911 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001
| ضع علامة كمهمة
https://www.boxbe.com/popup؟url=https٪3A٪2F٪2Fwww.boxbe.com٪2Fcleanup٪3Fkey٪3Doth٪252FFbAPG٪252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ٪253D٪26token٪3DHe7HfTrm٪252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp٪252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy٪252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A٪253D٪ 253D٪ 26important٪ 3Dtrue٪ 26emlId٪ 3D61245244440 & tc_serial = 30894750852 & tc_rand = 1847060911 & utm_source = stf & utm_medium = email & utm_campaign = ANNO_CLEANUP_EDIT & utm_content = 001

tparikka https://github.com/tparikka أوصي بشدة بذلك بالضبط
اقترب من نفسي.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-308521058 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAHNVmEzVDbw32Xx0jkYcGK9bZW3tLvXks5sECh8gaJpZM4CUZ8r
.

لم أفكر في استخدام LevelOfParallelism حتى الآن. يتم تعيينه افتراضيًا على عدد النوى التي لديك.

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

CharliePoole أنا أستخدم TestcaseSource ، لكن يبدو أن حالات الاختبار الناتجة لا يتم تنفيذها فعليًا بالتوازي. هل من المتوقع أن ينجح شيء كهذا:

ج #
[تثبيت إختبار]
فئة إلغاء التسلسل
{
عام ثابت I عدد لا يحصىshouldDeserializeAllCases () => Enumerable.Repeat (0، 5). اختر (x => TimeSpan.FromSeconds (2)) ؛

    [TestCaseSource("ShouldDeserializeAllCases"), Parallelizable(ParallelScope.Children)]
    public void ShouldDeserializeAll(TimeSpan t)
    {
        Thread.Sleep(t);
        Assert.AreEqual(1, 1);
    }
}

""

الوقت الإجمالي المستغرق هو 10 ثوانٍ بدلاً من ~ 2.

أعتقد أنه لا يوجد أطفال ، لذلك في هذه الحالة ، يمكنك استخدام أفضل
[Parallelizable (ParallelScope.All)]
أو نقل السمة الخاصة بك على مستوى الفصل.

تضمين التغريدة أنا في الواقع أطير عمياء فيما يتعلق بما تعنيه تلك السمة ، لذلك جربت جميع قيم التعداد هناك. بغض النظر عن أي من All أو Children أو Fixture أو Self أستخدمه ، أحصل على 10 ثوانٍ من وقت التنفيذ (على الأقل في Visual Studio).

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

جرب هذا مصدر إلهام :)

class Deserialization
{
    public static IEnumerable<TestCaseData> ShouldDeserializeAllCases
    {
        get
        {
            for (int i = 1; i <= 5; i++)
                yield return new TestCaseData(TimeSpan.FromSeconds(i)).SetName($"Thread_worker_{i}");
        }
    }

    [TestCaseSource(nameof(ShouldDeserializeAllCases)), Parallelizable(ParallelScope.Children)]
    public void ShouldDeserializeAll(TimeSpan t) => System.Threading.Thread.Sleep(t);
}

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

حاول إضافة [التجميع: LevelOfParallelism (5)] إلى AssemblyInfo ، أعتقد أن هناك بعض القيمة الافتراضية ، ولكن ربما لا تعمل معك بطريقة ما. على أي حال ، نفدت الأفكار لدي. :)