Nunit: دعم "اختبار dotnet" في .NET CLI و .NET Core

كنا ننتظر أن يستقر NET Core قليلاً قبل أن نتقدم مع # 927 ، ولهذا السبب لم يتم تحديثه بعنوان ومعلومات جديدة. كنت أخطط لانتظار أي إعلانات قد تصدر في // build قبل المضي قدمًا ، لكننا نقدر أي مساعدة يمكننا الحصول عليها. تتمثل خطتي في البدء في تقديم المزيد من الدعم الكامل لمزيد من الأنظمة الأساسية مع الإصدار 3.4 هذا الصيف بما في ذلك .NET Core و UWP و Xamarin.

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

كانت الخطوة الأولى في هذه العملية هي إنشاء برنامج تشغيل / وكيل PCL يمكنه تحميل وتنفيذ الاختبارات دون التقيد بإحكام بإصدار معين من NUnit Framework مثل NUnitLite و Xamarin runner الحالي. لا يزال في مهده ، لكن العمل قيد التقدم في مشروع nunit.portable.agent .

أي مساعدة أو نصيحة يمكن أن تقدمهاpiotrpMSFT أو livarcocc ستكون موضع تقدير أيضًا: ابتسم:

rprouse لدي خطأ في CLI لكتابة وثائق أفضل فيما يتعلق بالتفاعلات والمتطلبات بين اختبار dotnet والعداء. سأقوم بإنجازه اليوم أو غدًا وسأضع رابطًا له هنا.

هذا هو الخطأ الذي يتتبعه: https://github.com/dotnet/cli/issues/1803.

كيف يجري هذا؟ أود استخدام هذا ، ويبدو أن النظام البيئي dotnet cli يستقر.

أنا أحقق بعض التقدم ، لكنني لا أريد أن أفعل الكثير حتى يسقط RC2. لقد سئمت من محاولة مواكبة التغييرات: ابتسم:

تم إصدار NET Core RC2 وتتوفر معلومات جديدة. روابط كمرجع.

• أمر اختبار dotnet
• بروتوكول اتصال اختبار dotnet

هل يمكنني المساعدة هنا؟ هذا مانع لإكمال بعض منافذنا مثل StackExchange.Redis.

NickCraver يمكنني بالتأكيد استخدام بعض المساعدة ، تلك القراءة الأولى لبروتوكول الاتصال لم تجعل الأمور واضحة بشكل رهيب: ابتسم:

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

ثم أحتاج إلى إلقاء نظرة على ما يتطلبه الأمر لإنشاء امتداد اختبار للأمر dotnet .

أخيرًا ، أود أن يكون محرك nunit قادرًا على التشغيل والتواصل مع وكيل nunit أساسي حتى تتمكن وحدة التحكم nunit3 من تشغيل اختبارات وحدة .NET Core. لقد كنت أعمل على هذا ، ولكن لا يزال لدي الكثير من العمل للقيام به هناك.

كيف تريد أن تساعد؟

rprouse أعتقد أنه سيتعين عليك امتلاك بنية أساسية لاستخدامها عبر الأنظمة الأساسية ،

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

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

NickCraver بدلاً من بذل الجهد في النقل إلى xUnit ، قد يكون من الأسهل إنشاء سطر أوامر NUnitLite runner لتشغيل اختبارات .NET Core. إنه ليس حلاً مثاليًا ، ولكنه ربما أقل قدر من العمل. إنه قديم بعض الشيء ، لكنني قمت بالتدوين حول كيفية القيام بذلك في اختبار .NET Core باستخدام NUnit 3 .

أنا أفعل ذلك بهذه الطريقة لعدد قليل من المشاريع الشخصية وهو عملي.

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

هل سيساعد في تقسيم هذا إلى مرحلتين - نوع من "سريعة وقذرة ، قد يكون لها اختراقات مروعة ، ولكن على الأقل دعنا نخرج شيئًا ما هناك" ثم إصدار تكامل أكثر اكتمالاً لاحقًا؟

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

jskeet وNickCraver يمكنك استخدام NUnit اليوم عبر برنامج "الإختراق" NUnitlite كما اقترحrprouse، لقد تم القيام بذلك لNpgsql لبعض الوقت الآن، وأنها تعمل بشكل جيد. إنه ليس الحل الأمثل ولكن يجب أن يحررك بالتأكيد يا رفاق.

roji : لقد dnxcore50 (كنت أستخدمه مع Noda Time لبعض الوقت) - ولكن باستخدام netstandard1.3 ، فإن التبعيات على NUnit و NUnitLite غير صالحة.

jskeet يستهدف مشروعي الاختباري netcoreapp1.0 ويعتمد على Nunit + NUnitLite 3.2.1. لدي "imports" : [ "dotnet54" ] وهو يعمل مثل السحر ...

roji : شكرا على ذلك ... عبرت الأصابع ...

roji : ما زلت أواجه مشكلة في إجراء الاختبارات فعليًا - هل يمكنك الارتباط بالمكان الذي تقوم فيه بذلك في مشروع الاختبار الخاص بك ، كمثال يحتذى به؟

jskeet بالتأكيد ، https://github.com/npgsql/npgsql/tree/dev/test/Npgsql.

jskeet يجب أن تعمل الواردات معك أيضًا. يغير RC2 بعض الأشياء ، لذلك سأعيد كتابة منشور المدونة الخاص بي حول كيفية الاختبار باستخدام NUnit 3 مع وضع RC2 في الاعتبار وإرسال الكود إلى GitHub. سأضيف رابطًا هنا عند الانتهاء ، آمل أن يكون هذا الصباح (بتوقيت شرق الولايات المتحدة).

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

لقد قمت بنشر منشور مدونة محدث اختبار .NET Core RC2 باستخدام NUnit 3 لأي شخص مهتم.

jskeet ، فأنت بحاجة إلى بيان الواردات في project.json الخاص بك. تتم إضافته افتراضيًا في قوالب .NET Core الجديدة ، ولكن يجب إضافته عند الترقية.

لـ project.json في عداء وحدة التحكم ؛

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }

أو في مجلس ؛

  "frameworks": {
    "netstandard1.5": {
      "imports": "dnxcore50"
    }

عند الترقية إلى RC2 ، فإن وجود عناصر DNX القديمة في طريقي يؤدي إلى تقطعي أيضًا. شيء للتحقق.

rprouse : شكرا ؛ أنا الآن قادر على البناء ، والاختبارات تعمل على Windows. في نظام التشغيل Linux ، أشاهد "مرجع كائن لم يتم تعيينه على مثيل لكائن". رسالة على dotnet run ، والتي أحتاج إلى مزيد من التحقيق. سنحاول عينة الحد الأدنى لمعرفة ما إذا كان لديه نفس المشكلة ...

jskeet ، نحن نستخدم هذا الأسلوب على كل من Windows و Linux بدون مشكلة. انظر هنا وهنا للحصول على أمثلة.

oschwald : نعم ، يبدو أن مشكلة "مرجع الكائن لم يتم تعيينه ..." هي مشكلة منفصلة جدًا مع التبعيات. إنه لأمر مخز أن تكون رسالة الخطأ غير مفيدة للغاية (بدون حتى تتبع مكدس) - أنا أحفر فيها.

jskeet هناك عدة أسباب ، هل هذا لك؟ https://github.com/dotnet/cli/issues/3075

NickCraver : كلا - لقد أجريت استعادة dotnet بنجاح.

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

jskeet Gotcha - ذات صلة: https://github.com/dotnet/cli/issues/2469 وقناة Slack رائعة لتصحيح الأخطاء الحية project.json ، قم بإسقاط الأمثلة ويمكنك عادةً البدء بسرعة كبيرة. بالنسبة إلى Slack ، فإن قنوات #general و # dotnet-core نشطة جدًا ، والكثير من الأشخاص يمرون بهذا الأمر ويساعدون الشخص التالي.

حسنًا ... وهي تعمل الآن. من المحتمل أن تكون _was_ نفس المشكلة التي أبلغ عنها @ NickCraver ، وأنني كنت فقط dotnet restore المشروع الخاطئ لإصلاحه. على أي حال ، أقوم الآن بإجراء اختبارات Noda Time على Linux ، لذا شكرًا للجميع.

piotrpMSFT re طلبي للمؤشرات ، لقد وجدت كل ما أحتاجه وبدأت العمل.

لقد أضفت PR أولية لـ dotnet-test-nunit عداء في nunit / dotnet-test-nunit # 1

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

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

rprouse : يسعدني أن أرى كيف يتكيف Noda Time معها ، إذا كان ذلك سيكون مفيدًا. اسمحوا لي أن أعرف إذا كان هناك أي شيء على وجه الخصوص تريد مني أن أطلع عليه. شكرا لكل ماقمت به من عمل.

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

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

هنا هي لقطة الشاشة.

rprouse : أي تقدم في بناء CI؟ بالتأكيد حريص على ركل الإطارات ؛ يستخدم Noda Time عددًا _ معقولاً_ من ميزات NUnit ، لذا يجب أن تكون بداية جيدة ، على أي حال. أتطلع حقًا إلى القدرة على إجراء الاختبارات في VS مرة أخرى. (Hope NCrunch و CodeRush لـ Roslyn تبدأ في دعمها بمجرد خروجها أيضًا ...)

jskeet والآخرين المهتمين بركل الإطارات ومساعدتي في الاختبار قبل إصدار ألفا ، لقد قمت بتحديث المستودع التجريبي الخاص بي في فرع dotnet-test-nunit لاستخدام العداء الجديد dotnet-test-nunit .

يرجى الإبلاغ عن المشكلات في nunit / dotnet-test-nunit repo .

تعليمات عالية المستوى هي ؛

تحديث: dotnet-test-nunit متاح الآن كألفا على NuGet ، حدد Include prereleases . لم تعد بحاجة إلى تحديث ملف nuget.config الخاص بك.

dotnet-test-nunit قيد التطوير ، لذا ستحتاج إلى إضافة ملف NuGet.Config إلى الحل الخاص بك لتنزيل حزم NuGet من خلاصات NUnit CI NuGet.

يجب أن يبدو project.json الخاص بك في مشروعك الاختباري كما يلي ؛

مشروع json

{
    "version": "1.0.0-*",

    "dependencies": {
        "NUnitWithDotNetCoreRC2": "1.0.0-*",
        "NETStandard.Library": "1.5.0-rc2-24027",
        "NUnit": "3.2.1",
        "dotnet-test-nunit": "3.4.0-alpha-1"
    },
    "testRunner": "nunit",

    "frameworks": {
        "netstandard1.5": {
            "imports": [
                "dnxcore50",
                "netcoreapp1.0",
                "portable-net45+win8"
            ]
        }
    },

    "runtimes": {
        "win10-x86": { },
        "win10-x64": { }
    }
}

خطوط الاهتمام هنا هي التبعية على dotnet-test-nunit . لا تتردد في استخدام أحدث إصدار تجريبي ينتهي بـ -CI ، وهو الأحدث من الفرع الرئيسي. لاحظ أن التبعية NUnitWithDotNetCoreRC2 هي المشروع قيد الاختبار.

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

يمكنك الآن تشغيل اختباراتك باستخدام Visual Studio Test Explorer ، أو عن طريق تشغيل dotnet test من سطر الأوامر.

# Restore the NuGet packages
dotnet restore

# Run the unit tests in the current directory
dotnet test

# Run the unit tests in a different directory
dotnet test .\test\NUnitWithDotNetCoreRC2.Test\

تحذير

كما قلت ، هذا لا يزال قيد التطوير. يحتوي الإصدار 3.3.0.39-CI من dotnet-test-nunit المذكور أعلاه على خطأ حيث سيؤدي إلى ظهور ArgumentException عندما يحاول حفظ الملف TestResult.xml .

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

جزء "ابتلاع الخط الفارغ" خطأ معروف: https://github.com/dotnet/cli/issues/2234

شكرًا للرابط jskeet ، يبدو أن اللون هو أيضًا خطأ معروف ، dotnet / cli # 1977

تم إصلاح ArgumentException في 3.3.0.49-CI . سوف أقوم بتحديث تعليماتي أعلاه مع الإصلاح. إحدى المشكلات البارزة الأخرى هي أنني لا أقوم حاليًا بتزويد العداء برقم السطر للاختبارات ، لذا فإن النقر فوق الاختبارات في Visual Studio Test Explorer لن يأخذك إلى الكود.

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

لقد جربت project.json مختلفًا قليلاً بالنسبة لك. لقد أدرجته أدناه حرفيًا ، لكن الاختلافات المهمة هي:

• أرغب في اختبار وقت تشغيل سطح المكتب أيضًا ، لذلك لدي هدفان لإطار العمل
• أنا أستخدم netcoreapp1.0 بدلاً من netstandard1.5
• لقد قمت بتضمين التبعية Microsoft.NETCore.App ، مع "type"="platform"
• انظر أماه ، لا يوجد قسم وقت التشغيل. (ربما بسبب بعض التغييرات المذكورة أعلاه ...)

{
  "buildOptions": {
    "keyFile": "../../NodaTime Release.snk",
    "embed": {
      "include":  [   
        "TestData/*"
      ]
    }
  },

  "configurations": {
    "Debug": {
      "buildOptions": {
        "define": [ "DEBUG", "TRACE" ]
      }
    },
    "Release": {
      "buildOptions": {
        "define": [ "RELEASE", "TRACE" ],
        "optimize": true
      }
    }
  },

  "dependencies": {
    "NodaTime": { "target": "project" },
    "NodaTime.Testing": { "target": "project" },
    "NUnit": "3.2.1",
    "dotnet-test-nunit": "3.3.0.49-CI",
    "Microsoft.CSharp": "4.0.1-rc2-24027",
    "System.Dynamic.Runtime": "4.0.11-rc2-24027",
    "System.Reflection.Extensions": "4.0.1-rc2-24027",
    "System.Xml.XDocument": "4.0.11-rc2-24027"
  },

  "testRunner": "nunit",

  "frameworks": {
    "net451": {
      "frameworkAssemblies": {
        "System.Runtime": "",
        "System.Threading.Tasks": "",
        "System.Xml.Linq": ""
      }
    },
    "netcoreapp1.0": {
      "imports" : [ "dnxcore50", "netcoreapp1.0", "portable-net45+win8" ],
      "buildOptions": {
        "define": [ "PCL" ]
      },
      "dependencies": {
        "Microsoft.NETCore.App": { 
          "version": "1.0.0-rc2-3002702",
          "type": "platform"
        },
        "System.Console": "4.0.0-rc2-24027",
      }
    }
  }
}

نتيجة:

Test Count: 15141, Passed: 15141, Failed: 0, Inconclusive: 0, Skipped: 0

ووت. (باستخدام net451 ، أحصل على اختبار يبلغ 15646 ، وهو ما أتوقعه).

بعد ذلك: تجربة نفس الشيء على جهاز Linux (حيث من المفترض أن لا يعمل project.json الخاص بك بدون تعديل لأنه لا يذكر Linux ، ولكن يجب أن يكون لي ، من الناحية النظرية ؛ بعد أن قلت ذلك ، إنه جهاز Ubuntu 16.04 لذا فهو تترابط إلى حد ما dotnet CLI معًا).

همم. لم تنته الاختبارات على Linux بعد 14 دقيقة من تناول وحدة المعالجة المركزية بنسبة 100٪. سيحتاج إلى إلقاء نظرة فاحصة على ما يحدث هناك.

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

هل أنا محق في القول أنه لا يوجد دعم حجة سطر أوامر حتى الآن ، مثل - أين وما إلى ذلك؟

تم اختباره بشكل سيئ ، لكنني قمت بتوصيل السلك --where ومعظم معلمات سطر الأوامر الشائعة. ما زلت أواجه مشكلة ، nunit / dotnet-test-nunit # 4 للتحقق من أنها كلها سلكية بشكل صحيح وتعمل وإضافة أي شيء قد يكون مفقودًا. حتى الآن ، لم أختبر الكثير ، لكنني استخدمت القليل من خلال إضافتهم إلى نهاية الأمر dotnet . ما زلت بحاجة إلى معرفة كيفية عملها بالضبط. على سبيل المثال ، كان خيار سطر الأوامر --debug يعمل بشكل جيد من حل dotnet-test-nunit ، لكنه يطرح dotnet-test Error: 0 : Microsoft.DotNet.Cli.Utils.CommandUnknownException: No executable found matching command "dotnet-test-" عندما أقوم بتشغيله من حل الاختبار الخاص بي. ليس لدي أي فكرة أيضًا عن كيفية ربط سطر أوامر المساعدة بسطرنا لإظهار ما هو مدعوم.

في غضون ذلك ، يمكنك إلقاء نظرة على https://github.com/nunit/dotnet-test-nunit/blob/master/src/dotnet-test-nunit/CommandLineOptions.cs لمعرفة خيارات سطر الأوامر التي أعتقد أنها مدعوم: ابتسامة:

آه ، نعم - يبدو أن dotnet test ليس لديه نفس تسهيلات dotnet run لفصل الوسائط إلى إطار الاختبار من الوسائط إلى dotnet test نفسها. كنت أحاول

dotnet test -- --help

و

dotnet test -- --where=cat!=Slow

فقط باستخدام

dotnet test --where=cat!=Slow

يعمل بشكل جيد. سوف تقدم طلب ميزة لذلك - من الجيد أن تكون قادرًا على عدم الغموض تمامًا.

تم الآن إصلاح النقر فوق الاختبارات والتنقل إلى الكود في 3.3.0.60-CI .

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

• [x] nunit / dotnet-test-nunit # 22 إضافة رسائل وتتبع مكدس للاختبارات الفاشلة
• [x] nunit / dotnet-test-nunit # 12 TestContext.WriteLine لا يظهر في ملخص اختبار TestExplorer

تمامًا مثل FYI ، أجريت اختبارات Noda Time مرة أخرى اليوم على صندوق Ubuntu الخاص بي ، وتم الانتهاء منها بعد حوالي 15 دقيقة. يبدو أنهم جميعًا يعملون بمعدل 5-6x أبطأ على نظام التشغيل Linux i5 الخاص بي مقارنةً بنظام Win10 i7 الخاص بي. لست متأكدًا من مدى ارتباط ذلك بوحدة المعالجة المركزية ومقدار ما يجب فعله مع JIT - وهو بالتأكيد خارج نطاق NUnit :)

jskeet شكرًا على التحديث ، هذه أخبار جيدة. هل احتجت إلى روابط أحادية لاختبارات Linux كما هو موضح في nunit / dotnet-test-nunit # 9؟

بالنسبة لأي شخص يقوم بالاختبار ، فإن أحدث حزمة NuGet جيدة هي 3.3.0.69-CI ، يرجى اختبار ذلك. لا توجد الآن مشكلة معلقة أعتقد أنها خطيرة بما يكفي لمنع إصدار. إذا لم يتم الإبلاغ عن أي شيء هذا الأسبوع ، فمن المحتمل أن أقوم بإنشاء إصدار ألفا لاحقًا هذا الأسبوع أو أوائل الأسبوع المقبل. بمجرد أن أفعل ذلك ، سأغلق هذه المشكلة ويمكن أن تستمر المناقشات / القضايا المستقبلية في الريبو dotnet-test-nunit .

اختبر الآن أو إلى الأبد صمت: ابتسم:

rprouse : لم أحاول تشغيله على Mono - فقط .NET Core على Linux. سارت الأمور بشكل جيد مع project.json بالضبط أعلاه.

سيعطي 69-CI دوامة ...

أحد الاختلافات التي لاحظتها بين هذا وتشغيل تطبيق وحدة التحكم هو أن إصدار "اختبار dotnet" يبدو أنه يتضمن الوقت المستغرق في البحث عن الاختبارات في المدة الإجمالية ، بينما لم يكن الأمر "تشغيل dotnet" الذي استخدمته مع NUnitLite . في Noda Time ، هذا يعني أنه إذا أجريت مع --where=cat==Foo (لا توجد مثل هذه الاختبارات في هذه الفئة) ، فإن "اختبار dotnet" يبلغ عن مدة 14 ثانية حيث يبلغ "تشغيل dotnet" مدة 0.01 ثانية - على الرغم من كلاهما يستغرق نفس الوقت الحقيقي المنقضي.

هل هذا متعمد؟ أنا بالتأكيد لا أمانع في السلوك ، ولكن قد يكون من الجدير بالذكر أنه في مكان ما لتجنب اعتقاد الناس أنه في الواقع أبطأ.

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

لقد قمت بإصدار إصدار ألفا dotnet-test-nunit على GitHub على https://www.nuget.org/packages/dotnet-test-nunit/3.4.0-alpha-1 ، لذلك لم تعد بحاجة إلى تغيير NuGet.config واستخدم إصدارات CI.

الآن بعد أن خرجت ألفا ، سأغلق هذه المشكلة. الرجاء مساعدتي في اختبار ألفا والإبلاغ عن أي مشاكل في https://github.com/nunit/dotnet-test-nunit/issues. من المقرر أن يخرج الإصدار النهائي في نهاية الشهر مع إصدار NUnit 3.4. سأصدر إصدارات ألفا وبيتا المحدثة اعتمادًا على المشكلات التي تم العثور عليها.

لقد قمت بتحديث الوثائق في الملف التمهيدي لـ dotnet-test-nunit . سأبقي ذلك محدثًا.

https://github.com/nunit/dotnet-test-nunit

كما أشرت من قبل ، لست بحاجة إلى تحديد أوقات التشغيل إذا كنت تستخدم "type": "platform" "Microsoft.NETCore.App" للتبعية

لدي حاليًا طلب سحب يتم تشغيله عبر Travis - إذا تحول ذلك إلى اللون الأخضر ، فسيعتمد Noda Time على هذا ، لذا يجب أن يمنحه هذا __ بعض_ الاستخدام. أحسنت يا سيدي ...

أحد الجوانب السلبية التي لاحظتها للتو - هذا يعني أنه لم يعد بإمكاني الاختبار بسهولة مع Mono على Linux. أعتقد أن هذه ليست مشكلة NUnit ، إنها في الأساس مظهر من مظاهر https://github.com/dotnet/cli/issues/3073 ولكن لـ NUnit. ما زلت آمل أنه قد يتم إصلاحه في النهاية ؛ في الوقت الحالي ، سأقوم بتعطيل اختباراتي الأحادية في ترافيس ، مع قليل من التردد. ( dotnet test هو المستقبل بالتأكيد).