Nunit: اختبارات الوحدة الفاشلة في اختبارات nunit.framework.tests بعد استنساخ جديد

تم إنشاؤها على ٢٥ يونيو ٢٠١٨  ·  31تعليقات  ·  مصدر: nunit/nunit

لقد حصلت للتو على نسخة جديدة من nunit وفتحت الحل في Visual Studio 2017 (المجتمع 15.7.4) مع أحدث محول اختبار NUnit 3 (3.10 مع اختبارات التشغيل بالتوازي) يعمل على Windows 10 Professional وحدد "Debug-AnyCPU "وضرب البناء.

بعد قراءة BUILDING.md ، يبدو أنني يجب أن أتجاهل أي إخفاقات لا تأتي من nunit.framework.tests- * و nunitlite.tests- *

ولكن خارج البوابة أحصل على إخفاقين من nunit.framework.tests- *

أول خطأ:

Test Name:  TestCaseSourceCanAccessWorkDirectory("C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20")
Test FullName:  NUnit.Framework.TestContextTests.TestCaseSourceCanAccessWorkDirectory("C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20")
Test Source:    C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\TestContextTests.cs : line 110
Test Outcome:   Failed
Test Duration:  0:00:00.001

Result StackTrace:  at NUnit.Framework.TestContextTests.TestCaseSourceCanAccessWorkDirectory(String workDirectory) in C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\TestContextTests.cs:line 112
Result Message: 
Expected string length 34 but was 50. Strings differ at index 34.
  Expected: "C:\\Users\\ace.olszowka\\source\\nunit"
  But was:  "C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20"
  -------------------------------------------------^

بالنظر إلى المصدر ، لا أرى كيف كان ذلك ممكنًا ، بقدر ما أستطيع أن أقول إن هذه القيم يجب أن تكون متطابقة ( _workDirectory وكلاهما تم تعيين بيانات الاختبار على TestContext.CurrentContext.WorkDirectory ) فقط تخمين نوع من حالة السباق ، ربما بسبب التكوين السيئ من طرفي؟

الخطأ الثاني:

Test Name:  StackTracesAreFiltered("WarningInBeginInvoke",4)
Test FullName:  NUnit.Framework.Assertions.WarningTests.StackTracesAreFiltered("WarningInBeginInvoke",4)
Test Source:    C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\Assertions\WarningTests.cs : line 292
Test Outcome:   Failed
Test Duration:  0:00:00.004

Result StackTrace:  at NUnit.Framework.Assertions.WarningTests.StackTracesAreFiltered(String methodName, Int32 maxLineCount) in C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\Assertions\WarningTests.cs:line 310
Result Message: 
Multiple failures or warnings in test:
  1) (Warning message)
  2) Expected the number of lines to be no more than 4, but it was 5:

 1. at NUnit.TestData.WarningFixture.<>c__DisplayClass45_0.<WarningInBeginInvoke>b__0()
 2. at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
 3. at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
 4. at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object o)
 5. at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
(end)

لقد ضللت في ما يحاول هذا الاختبار القيام به هنا ؛ ولكن بناءً على فهمي المحدود ، يبدو أن هذا الرمز حساس حقًا تجاه أي تغييرات في مكدس المكالمات ، فهل يمكن أن يكون هذا بسبب تغيير حديث في .NET Framework؟

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

نظرًا لأن الإنشاء يمر في CI ، ربما تكون هذه مجرد مشكلات تكوين من ناحيتي ، ولكن لم يتم ذكر أي شيء في BUILDING.md حول هذا الأمر ، لذا اعتقد أن التقرير كان يستحق كل هذا العناء.

bug normal
مصدر
picture aolszowka
👍1

ال 31 كومينتر

شكرا على التقرير! لقد أكدت أن TestCaseSourceCanAccessWorkDirectory و CommandLineTests لا يعملان في Test Explorer. نحن بحاجة إلى إيجاد طريقة لجعلها مستقلة عن العداء والتوازي. @ nunit / framework-team أي أفكار؟

بالنسبة للخطأ الثاني ، هذا اختبار للرائحة. من المنطقي رفع ذلك إلى الرقم 5.

jnm2 picture jnm2 في ٢ يوليو ٢٠١٨
👍1

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

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

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

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

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

CharliePoole picture CharliePoole في ٢ يوليو ٢٠١٨
👍1

FWIW من الخارج بالنظر إلى الداخل: لا يهمني حقًا الطريقة التي تقطع بها ما دامت موثقة على هذا النحو.

من خارج الصندوق ، سأحاول كمطور أن أفعل ما أفعله عادة عندما أواجه أي مشروع جديد يستخدم نفس الممارسات التي أستخدمها داخليًا:

  1. استنساخ الكود
  2. اقرأ الملف README.md/BUILD.md/HACKING.md
  3. محاولة بناء (بدون تغييرات)
  4. قم بإجراء اختبارات الوحدة (عبر العداء المتكامل).
  5. إذا كان كل شيء يعمل ابدأ باللعب مع الأشياء.

في الماضي ، كان هذا بمثابة dotCover الخاص بـ ReSharper ، لكننا كنا نحاول أن نفطم أنفسنا عنه لأن تكاليف الترخيص مجنونة للمتاجر الصغيرة / المطورين الأفراد عندما تكون هناك بدائل برامج مجانية / مفتوحة المصدر "تعمل في الغالب".

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

ومع ذلك ، إذا كان من المتوقع أن نستخدم Console Runner (أو عداء آخر) فهذا جيد في ذهني ، فقط قم بتوثيقه.

aolszowka picture aolszowka في ٢ يوليو ٢٠١٨

إذا كنت تقوم بالتطوير على NUnit ، وتعمل على إطار العمل ، أعتقد أن الاختلاط في أي متسابقين يقومون بأشياء بطرق خاصة (R # ، محولنا الخاص) يمكن أن يربك المشكلة. أحب أن أعرف أن إطار العمل يعمل بشكل صحيح بمعزل عن الآخرين قبل اختباره مع العدائين. لذلك في عملي الخاص ، أستخدم nunitlite للاختبار بينما أقوم بتطوير ثم تشغيل CI محليًا. إذا أراد شخص ما التطوير على NUnit في Test Explorer ، فسأقول إنه لا يزال يتعين عليه تشغيل CI محليًا ويجب أيضًا الرجوع إلى وحدة التحكم nunitlite أو nunit3 عندما يبدو أي شيء مخادعًا.

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

CharliePoole picture CharliePoole في ٢ يوليو ٢٠١٨

يجب أن نجعل CI أساسيًا ، ربما باستخدام NUnitLite لجميع اختبارات إطار العمل ثم وحدة التحكم ومحول VSTest و عداء UWP للاختبارات الشاملة.

بافتراض أن CI قوي ، يبدو الأمر جيدًا بالنسبة لي إذا كانت هناك اختلافات دقيقة بين Test Explorer و ReSharper و NCrunch و CI script. إن القول بأنه يجب تجاهل هذه الأدوات في IDE هو شيء أراه عائقًا أمام المساهمة وهو خطأ لأن هذا ليس حتى سير العمل الخاص بي. سير العمل المثالي لدي:

  1. حدد موقع الاختبارات الحالية أو اكتب اختبارات جديدة
  2. قم بتثبيت أداة الاختبار هذه لتسريع إعادة إجراء الاختبارات أثناء الكتابة (حتى أفضل ، ابدأ الاختبار المستمر)
  3. تنفيذ التغيير
  4. قبل إنشاء التزام Git ، قم بتشغيل .\build.ps1 -t test للتأكد من أن التمريرات والإخفاقات كما هو متوقع
  5. إذا كانت هناك أي مفاجآت ، فابحث عن الاختبارات المتأثرة التي لم أكن أعرفها وقم بتثبيتها وانتقل إلى الخطوة 3

في السيناريو النادر حيث تكون الاختبارات حساسة للعدائين ، لست متأكدًا من صعوبة جعلها غير حساسة للعداء. لا يمكن أن يكون أسوأ من اختبارات التكامل التي كتبتها لـ ILMerge والتي جعلتها مرنة مع النسخ الاحتياطية ReSharper و NCrunch.

jnm2 picture jnm2 في ٢ يوليو ٢٠١٨

aolszowka أتفق 100٪ مع وجهة نظرك بأنه مهما فعلنا ، يجب أن نحترم وقت المساهمين من خلال الحفاظ على سهولة استهلاك مستندات المساهمة وتحديثها.

jnm2 picture jnm2 في ٢ يوليو ٢٠١٨

@ jnm2 أحب

لا يزال من المفيد ، من الضروري ، لأي شخص يعمل على nunit أن يعرف متى يتحول إلى مستوى أقل من الاختبار.

أكبر شيء يمكننا القيام به لدفع هذه الفكرة إلى الأمام IMO هو إنشاء نظام منفصل وربما اختبارات تكامل.

CharliePoole picture CharliePoole في ٢ يوليو ٢٠١٨
👍1

قد يكون هذا هو السبب الجذري. أثناء كتابة الاختبارات للحصول على XML من FrameworkController ، لاحظت أنه تم تغيير TestContext.WorkDirectory إلى C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE :

https://github.com/nunit/nunit/blob/81fcc7c047c09fcb5a86989d0829716ca7d08e1e/src/NUnitFramework/framework/Api/DefaultTestAssemblyBuilder.cs#L137

مكدس الاستدعاء:

>   nunit.framework.dll!NUnit.Framework.Api.DefaultTestAssemblyBuilder.Build(System.Reflection.Assembly assembly, string suiteName, System.Collections.Generic.IDictionary<string, object> options) Line 137    C#
    nunit.framework.dll!NUnit.Framework.Api.DefaultTestAssemblyBuilder.Build(string assemblyNameOrPath, System.Collections.Generic.IDictionary<string, object> options) Line 114    C#
    nunit.framework.dll!NUnit.Framework.Api.NUnitTestAssemblyRunner.Load(string assemblyNameOrPath, System.Collections.Generic.IDictionary<string, object> settings) Line 154   C#
    nunit.framework.dll!NUnit.Framework.Api.FrameworkController.LoadTests() Line 204    C#

يرجع السبب في ذلك إلى أن TestContext.WorkDirectory حالة ثابتة قابلة للتغيير:

https://github.com/nunit/nunit/blob/81fcc7c047c09fcb5a86989d0829716ca7d08e1e/src/NUnitFramework/framework/TestContext.cs#L96 -L101

هذا يعني أنه تمت مشاركته من قبل جميع الاختبارات (!) ، بما في ذلك الاختبارات المتزامنة. يجب وضع علامة على أي اختبار يعتمد على WorkDirectory [NonParallelizable] حتى يكون صحيحًا.

jnm2 picture jnm2 في ١٤ يوليو ٢٠١٨

لقد لاحظت هذه المشكلة منذ وقت طويل. هناك مشكلة حول هذا الموضوع في مكان ما.

غير المتكافئ لا يكفي. إذا قام أي اختبار بتعديل WorkDirectory (كما تفعل العديد من اختبارات NUnit) ، فهناك احتمال معقول بأن الاختبارات الأخرى التي تعتمد عليه ستفشل.

كل هذا يتوقف على الترتيب الذي يتم تنفيذ الاختبارات به ، وهو غير محدد في NUnit.

oznetmaster picture oznetmaster في ١٤ يوليو ٢٠١٨

النية هي أن دليل العمل يجب أن يتم تعيينه مرة واحدة وأن يظل دون تغيير للتشغيل. أي شيء آخر في الولايات المتحدة خطأ.

CharliePoole picture CharliePoole في ١٤ يوليو ٢٠١٨

هل هناك سبب يمنعنا من السماح بدليل عمل مستقل لكل سياق تنفيذ؟

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

jnm2 picture jnm2 في ١٤ يوليو ٢٠١٨

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

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

في السؤال ، يمكننا أن نجعله غير قابل للتغيير ونتوقف عن اختباره. <ducks>

CharliePoole picture CharliePoole في ١٤ يوليو ٢٠١٨

هذه في الواقع فكرة رائعة - تتبع ما إذا كان الحقل الثابت قد تم ضبطه وتخطي إعداده بعد ذلك؟ بهذه الطريقة ، لا يمكن تغييره ولا أرى أي اختبارات تتحقق مما إذا كان DefaultTestAssemblyBuilder يحدده ، لذلك يجب أن نكون جيدين!

jnm2 picture jnm2 في ١٤ يوليو ٢٠١٨

هناك اختبارات NUnit التي تغيرها ، وإذا تم جعلها غير قابلة للتغيير ، فقد تفشل.

oznetmaster picture oznetmaster في ١٤ يوليو ٢٠١٨

oznetmaster لقد بحثت ولكن لا يمكنني العثور على أي اختبارات NUnit تغيرها إلا عن طريق الخطأ. هل لديك أي مفيد؟

jnm2 picture jnm2 في ١٤ يوليو ٢٠١٨

سأضطر إلى البحث في أرشيفاتي.

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

                if (options.ContainsKey (FrameworkPackageSettings.WorkDirectory))
                    TestContext.DefaultWorkDirectory = options[FrameworkPackageSettings.WorkDirectory] as string;
                else
                    if (TestContext.DefaultWorkDirectory == null)
                        TestContext.DefaultWorkDirectory = Directory.GetCurrentDirectory ();
oznetmaster picture oznetmaster في ١٤ يوليو ٢٠١٨

كانت الاختبارات التي كانت هي المشكلة هي تلك التي من شأنها استدعاء DefaultTestAssemblyBuilder.Build مع الخيارات التي لم تتضمن FrameworkPackageSettings.WorkDirectory ، مما تسبب في استبدال TestContext.DefaultWorkDirectory بواسطة CurrentDirectory. هذا يعني أنه إذا تم تعيين WorkDirectory في تنفيذ المستوى الأعلى ، فسيتم الكتابة فوقه بواسطة الاختبار ، ولن يتم استعادته مطلقًا.

oznetmaster picture oznetmaster في ١٤ يوليو ٢٠١٨

يبدو أننا سنكون جيدين في اتباع نفس النهج بعد ذلك؟

jnm2 picture jnm2 في ١٤ يوليو ٢٠١٨

تناسبني. اجتاز بناء CF الخاص بي 100٪ من اختبارات NUnit.

oznetmaster picture oznetmaster في ١٤ يوليو ٢٠١٨
👍1

OmicronPersei إذا كنت إصلاح oznetmaster ؟

jnm2 picture jnm2 في ١٤ يوليو ٢٠١٨

نعم! سأحاول هذا المساء

OmicronPersei picture OmicronPersei في ١٧ يوليو ٢٠١٨

لا يمكنني حقًا إعادة إنتاج هذا الخطأ نظرًا لأن nunit3-vs-adaptor # 528 تسبب في حدوث مشكلات أخرى. أفكار؟

OmicronPersei picture OmicronPersei في ١٧ يوليو ٢٠١٨

تضمين التغريدة لا أدري، لا أعرف. هل استخدام .runsettings مع تعيين WorkDirectory بشكل صحيح سيكون حلاً جيدًا؟

jnm2 picture jnm2 في ١٧ يوليو ٢٠١٨

حسنًا ، لقد جربت ذلك. نجح TestCaseSourceCanAccessWorkDirectory لكن فشل StackTracesAreFiltered بنفس تتبع الرسالة / المكدس في OP.

OmicronPersei picture OmicronPersei في ١٧ يوليو ٢٠١٨

أعتقد أنه يجب اصطدام StackTracesAreFiltered بـ 5. إنه اختبار للرائحة حتى نلاحظ ما إذا تمت إضافة إطارات جديدة حتى نتمكن من التأكد من أنها لم تخرج عن نطاق السيطرة.

jnm2 picture jnm2 في ١٧ يوليو ٢٠١٨

ماذا عن TestCaseSourceCanAccessWorkDirectory ، أم أن هذا لا يزال في نطاق هذا العلاقات العامة؟

OmicronPersei picture OmicronPersei في ١٨ يوليو ٢٠١٨

ForTestCaseCanAccessWorkDirectory ، هل إصلاح oznetmaster يحلها؟ إذا لم يكن الأمر كذلك ، فسوف يتعين علينا إجراء مزيد من التحقيق.

jnm2 picture jnm2 في ١٨ يوليو ٢٠١٨

لا يمكنني إعادة إنتاج المشكلة على جهازي ، فالاختبار المعني ينجح بالنسبة لي.

OmicronPersei picture OmicronPersei في ٢٠ يوليو ٢٠١٨

لا تقلق ، يمكن لشخص آخر القيام بهذا الجزء. أحب وجود علاقات عامة أصغر أيضًا.

jnm2 picture jnm2 في ٢٠ يوليو ٢٠١٨

مجرد محاولة تنظيف المنزل ؛ هل هناك أي سبب لاستمرار فتح هذه المشكلة أم يمكننا إغلاقها بنوع من الحل؟ (حتى لو كان WONTFIX).

aolszowka picture aolszowka في ١٤ مايو ٢٠١٩
👍1

لا ، شكرا لتوضيح ذلك. إغلاق.

rprouse picture rprouse في ١٤ مايو ٢٠١٩
👍1
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

jnm2 picture jnm2  ·  112تعليقات
jnm2 picture jnm2  ·  43تعليقات
Ch0senOne picture Ch0senOne  ·  46تعليقات
mintsoft picture mintsoft  ·  70تعليقات
CharliePoole picture CharliePoole  ·  76تعليقات