Autofixture: قضايا تكامل NCrunch و AutoFixture

مرحبًا ، أنا مطور NCrunch.

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

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

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

remcomulder شكرا جزيلا لك على المشاركة هنا - في غاية الامتنان! لقد حققت في ذلك قليلاً وأود مشاركة النتائج التي توصلت إليها. جميع النتائج التي توصلت إليها قابلة للتطبيق على xUnit فقط .

TL DR: تدعم xUnit مثل هذه النظريات ويجب أن تدعمها NCrunch مع xUnit أيضًا. بالنسبة إلى NUnit - هذا سؤال مفتوح ولم أحقق في ذلك بعد.

يبدو أن الميزة التي نستخدمها هي _legal_ لـ xUnit. لدينا TestDataDiscoverer الخاص بنا والذي يشير إلى أن نظرياتنا لا يمكن اكتشافها مسبقًا (لأننا نولد بيانات عشوائية). في وقت لاحق قمنا بتزيين AutoDataAttribute الخاص بنا بهذا المكتشف. تحترم xUnit

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

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

ضع في اعتبارك رمز الاختبار التالي:

using Ploeh.AutoFixture.Xunit2;
using Xunit;

namespace Playground
{
    public class UnitTest
    {
        [Fact]
        public void StableTest()
        {
            Assert.True(true);
        }

        [Theory]
        [InlineData(1)]
        public void StableInlineTest(int value)
        {
            Assert.Equal(1, value);
        }

        [Theory, AutoData]
        public void VolatileTest(int value)
        {
            Assert.True(value % 2 == 0);
        }

        [Theory]
        [InlineAutoData(10)]
        [InlineAutoData(20)]
        [InlineAutoData(30)]
        public void VolatileTestWithInline(int value, int autoValue)
        {
            Assert.NotEqual(value, 40);
        }
    }
}

مشروع مكتبة اختبار .NET Framework. VS 2017.3. الإطار المستهدف: 4.5.2. الحزم المثبتة:

• xunit 2.2.0
• xunit.runner.visualstudio 2.2.0
• AutoFixture 3.50.6
• AutoFixture.Xunit2 3.50.6

إذا قمت بتشغيل الاكتشاف في VS ، فسترى الناتج التالي:

كما قد تلاحظ ، بالنسبة للنظريات التي تدعم اكتشاف البيانات ( StableInlineTest ) ، يعرض VS runner البيانات الفعلية التي سيتم تشغيل الاختبار بها ( 1 ). بالنسبة للاختبارات التي لا تدعم اكتشاف البيانات وتحتوي على بيانات تم إنشاؤها تلقائيًا ( VolatileTest ، VolatileTestWithInline ) لا تكتشف VS الحالات النظرية وتعرض لك النظرية بأكملها فقط. فقط بعد تشغيلك ، ستتمكن من رؤية قيم هذا الاستدعاء المعين:

يمكنك الآن إعادة تشغيل النظرية الخاصة وستعمل _جميع الحالات النظرية_ مرة أخرى.

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

الطريقة الوحيدة الموثوقة التي يمكنني التفكير فيها لحل هذه المشكلة هي إزالة كل الإنشاء العشوائي لمعلمات الاختبار واستخدام القيم الثابتة بدلاً من ذلك (مثل العناصر النائبة أو consts)

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

أو قصر نثر قيم المعلمات على حالة الاختبار نفسها.

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

بيانات الأعضاء

في التوثيق هنا لديك نموذج آخر (لقد أعدت كتابته إلى XUnit):

public class MemberDataSample
{
    public IEnumerable<object[]> GetData()
    {
        yield return new object[]
        {
            DateTime.Now
        };
    }

    [Theory, MemberData(nameof(GetData), DisableDiscoveryEnumeration = true)]
    public void DateTheory(DateTime dt)
    {
        Assert.True(DateTime.Now - dt < TimeSpan.FromMinutes(1));
    }
}

إنه قانوني تمامًا بالنسبة إلى xUnit نظرًا لوجود سمة DisableDiscoveryEnumeration . إنه يعمل مثل النموذج أعلاه - الحالات النظرية لا يتم اكتشافها مسبقًا.

الخط السفلي

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

بالنظر إلى أن كلاً من R # و VS يدعمان مثل هذه النظريات الرائعة ، فهذا يجعلني أعتقد أن كل شيء في الواقع مناسب لمنتجنا ..

بالنسبة إلى NUnit - فلنناقش ذلك بعد ذلك لأنني لم أحقق في ذلك بعد. ربما ، ليس لدينا مثل هذا API لذلك.

هل يمكنك مشاركة رأيك بخصوص دعم xUnit في ضوء النتائج التي توصلت إليها؟ سوف تضيف الدعم ل
xUnit (توقف عن إعادة تشغيل جميع الاختبارات) وتوقف لإظهار تحذير عدم التوافق هذا؟ 😉

يبدو أنني مدين لك باعتذار هنا. حالة الاستخدام التي وصفتها أعلاه تعمل بشكل صحيح ضمن NCrunch ، للأسباب التي أوضحتها. تتجنب Xunit التعداد المسبق للنظرية وتقوم بتدويرها في اختبار واحد حيث يتم تحديدها وتنفيذها بأمان. عند اختبار هذا الآن ، يمكنني أن أؤكد أن NCrunch يقوم بذلك بشكل صحيح. يبدو أنه ليس لدينا مشكلة واضحة مع InlineAutoData.

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

أود أن ألفت انتباهك إلى حالة استخدام محددة أدرك أنها ستؤدي إلى كسر كل من NCrunch و VS Runner. أفترض أنه سيؤدي أيضًا إلى تعطيل ReSharper و TD.NET ، على الرغم من أنني لم أختبرها لأنني لم أقم بتثبيتها:

using Ploeh.AutoFixture;
using Ploeh.AutoFixture.Xunit2;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Xunit;

namespace XUnitAutoFixture
{
    public class TestFixture
    {
        private static readonly Fixture Fixture = new Fixture();

        public static IEnumerable<object[]> SomeTestData()
        {
            yield return new object[] { Fixture.Create<string>() };
            yield return new object[] { Fixture.Create<string>() };
        }

        [Theory, MemberData(nameof(SomeTestData))]
        public void Test(object value)
        {

        }
    }
}

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

وافتراضي الحالي هو أنك لا تدعم مثل هذا السيناريو. هل هذا صحيح؟

عند اختبار هذا الآن ، يمكنني أن أؤكد أن NCrunch يقوم بذلك بشكل صحيح.

هذا جيد! يسعدنا سماع أن xUnit في الواقع مدعوم بالكامل من NCrunch 🎉 أما بالنسبة لـ NUnit - فقد كان دائمًا أخرق ونحتاج إلى التحقق مما يمكننا القيام به هناك.

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

هل هذا صحيح؟ إذا كانت الإجابة بنعم ، فهل يمكنك من فضلك إصلاح ذلك لتعطيل مثل هذا السلوك لـ xUnit لأن كل شيء على ما يرام هناك؟

أود أن ألفت انتباهك إلى حالة استخدام محددة أدرك أنها ستؤدي إلى كسر كل من NCrunch و VS Runner.
وافتراضي الحالي هو أنك لا تدعم مثل هذا السيناريو. هل هذا صحيح؟

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

public class TestFixture
{
    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { DateTime.Now.Ticks };
        yield return new object[] { DateTime.Now.Ticks };
    }

    [Theory, MemberData(nameof(SomeTestData))]
    public void Test(object value)
    {

    }
}

بالنسبة لمثل هذا السيناريو ، تقع على عاتقك مسؤولية تعطيل الاكتشاف المسبق يدويًا ، بحيث يبدو كالتالي (انتبه إلى الخاصية DisableDiscoveryEnumeration ):

public class TestFixture
{
    private static readonly Fixture Fixture = new Fixture();

    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { Fixture.Create<string>() };
        yield return new object[] { Fixture.Create<string>() };
    }

    [Theory, MemberData(nameof(SomeTestData), DisableDiscoveryEnumeration = true)]
    public void Test(object value)
    {

    }
}

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

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

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

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

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

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

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

لا داعى للقلق! كل شيء على ما يرام ونحن جميعًا هنا لمساعدة بعضنا البعض على فهم الأشياء من الرائع أنك تابعت التذكرة وناقشنا ذلك - إنه كثير جدًا 🥇

مع ما تعلمته منك ، أشعر بأنني مستعد لإزالة تحذير AutoFixture من NCrunch تمامًا.

حسنًا ، ما زلنا نواجه مشكلات مع NUnit (نحن في طريقنا على الرغم من ذلك) ، لذلك تبدو هذه الرسالة ذات صلة بمشاريع NUnit. ربما يكون من المنطقي تعطيل ذلك لـ xUnit فقط ، ما لم نقدم الدعم الكامل لـ NUnit (أو على الأقل طريقة لتمكين هذا الدعم).

لا يزال لدي شيء واحد غير واضح بالنسبة لي. ماذا يعني أنك لا تدعم مثل AutoFixture & NUnit؟ نعم ، تختلف أسماء الاختبار في كل مرة ، ولكن هل يهم إذا أعدت تشغيل جميع الاختبارات (إذا تم تعيين وضع المحرك على هذا النحو)؟ أم يعني أنك لا تدعم محرك "المتأثرين فقط" أكثر بالنسبة لهم؟ كان تفكيري أنه بدلاً من قول No support ، ربما يكون من الأفضل التضييق على بعض السيناريوهات المعينة التي لا ندعمها ، بينما يجب أن تكون بقية السيناريوهات جيدة.

"تشغيل الاختبارات المتأثرة تلقائيًا ، والاختبارات الأخرى يدويًا"

لم أتمكن من العثور على هذا الإعداد في تثبيت 3.10.0.20 . هل تقصد إعداد Only consider tests 'Out of date' if they are 'Impacted' الذي يجب تعيينه على true ؟ آسف إذا فاتني ذلك في مكان ما - فأنا جديد قليلاً على هذا المنتج ..

تحديث الوثائق

ربما يكون من المنطقي عدم _remove_ case مع xUnit و AutoFixture من هذه الصفحة ، ولكن بدلاً من ذلك وصف كيفية استخدامها بشكل صحيح (استخدم السمة DisableDiscoveryEnumeration ). كما سيكون من الرائع وصف نموذج "NUnit Test Case With Inconsistent Name" لـ xUnit واطلب استخدام السمة DisableDiscoveryEnumeration مع MemberDataAttribute .

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

هذا بسبب عمر الاختبار تحت NCrunch. لدى NCrunch حالة مهمة يتم تعيينها لكل اختبار (اعتقد نتيجة النجاح / الفشل ، بيانات تغطية الكود ، بيانات الأداء ، إخراج التتبع ، إلخ). تستمر هذه البيانات طالما استمر "اكتشاف" الاختبار بواسطة إطار عمل الاختبار ، حتى بين جلسات VS. عندما يشير إطار عمل الاختبار إلى عدم وجود اختبار بالمعرف نفسه ، يعتبر الاختبار قد انتهى ويتم إتلاف جميع الحالات.

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

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

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

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

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

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

لم أتمكن من العثور على هذا الإعداد في تثبيت 3.10.0.20 الخاص بي. هل تقصد أن الاختبارات التي تعتبر فقط "قديمة" إذا كانت "متأثرة" يجب تعيينها على "صواب"؟ آسف إذا فاتني ذلك في مكان ما - فأنا جديد قليلاً على هذا المنتج ..

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

تضمين التغريدة شكرا لمثل هذا الشرح التفصيلي! الآن أرى أنه من الأسهل بالفعل القول أن AutoFixture & NUnit لا يتم دعمهما حاليًا نظرًا لوجود بعض المشكلات الضخمة تحت الغطاء 😅

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

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

    [Test, StableNameAutoData]
    public void Sample(int a, Data d1, DataWithToString d2, ISomeData d3)
    {
        Assert.IsTrue(true);
    }

سيكون اسم الاختبار:

NUnit3RunnerTest709.TestNameTester.Sample(auto<System.Int32>,auto<NUnit3RunnerTest709.Data>,auto<NUnit3RunnerTest709.DataWithToString>,auto<Castle.Proxies.ISomeDataProxy>)

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

بالنظر إلى معرفتك العميقة بـ NUnit ، كيف تقيم هذا النهج؟ سوف يعمل لك؟ أتوقع أن تستخدم اسمًا نظريًا ، بدلاً من الارتباط بقيم حجة معينة. لذلك ، إذا كان اسم الاختبار مستقرًا ، فلن تواجه أي مشاكل لأنه يمكن التعرف عليه الآن. هل يمكنك التأكيد قبل أن نبدأ في تنفيذ هذا؟ ☺️

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

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

بالنظر إلى معرفتك العميقة بـ NUnit ، كيف تقيم هذا النهج؟ سوف يعمل لك؟ أتوقع أن تستخدم اسمًا نظريًا ، بدلاً من الارتباط بقيم حجة معينة. لذلك ، إذا كان اسم الاختبار مستقرًا ، فلن تواجه أي مشاكل لأنه يمكن التعرف عليه الآن. هل يمكنك التأكيد قبل أن نبدأ في تنفيذ هذا؟ ☺️

لسوء الحظ ، فإن معرفتي بـ NUnit بعيدة كل البعد عن العمق: تم إرجاعها بواسطة NUnit API ، ثم يجب أن نكون على ما يرام هنا
ل NCrunch على الأقل.

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

remcomulder فقط

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

لقد قمنا مؤخرًا بدمج PR وأصدرنا إصدارًا جديدًا من AutoFixture ( v3.51.0 ) والذي يضيف دعمًا للأسماء المستقرة لـ NUnit. في الوقت الحالي ، يلزم اتخاذ الإجراءات اليدوية من جانب المستخدم (انظر هنا ) ، ولكن في الإصدار 4 سأجعله خارج الصندوق.

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

zvirja شكرا

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

ألاحظ أنه بشكل افتراضي ، سيستخدم AutoFixture VolatileNameTestMethodBuilder. أوافق على ذلك لأسباب تتعلق بالتوافق مع الإصدارات السابقة وأوافق على أن هذا أمر معقول. ولكن ماذا لو سمحنا بتجاوز هذا الإعداد الافتراضي باستخدام متغير بيئة؟ إذا تمكنا من تحديد متغير بيئة (على سبيل المثال ، 'AutoFixture.FixedTestNames' == '1') لإجبار AutoFixture على استخدام VolatileNameTestMethodBuilder ، سيكون من الممكن للعداء تحديد المنشئ مقدمًا ، دون حاجة المستخدم إلى فعل أي شيء. سيكون هذا أيضًا مكافأة للأشخاص الذين يستخدمون عدائين متعددين ، حيث يمكنهم ضمنيًا استخدام بناة مختلفين لكل عداء (دون أي جهد مطلوب) والحصول على أفضل ما في العالمين.

ماذا تعتقد؟

لقد أعطيت هذا العمل اختبارًا سريعًا ، ويبدو لي أنه قوي.

هذا رائع! 🎉 بمعنى أنه يمكننا إغلاق هذه المشكلة لأن كل شيء يعمل بشكل جيد الآن. شكرا للاختبار ومشاركتك هنا 🥇

ماذا تعتقد؟

أعتقد أنني انتهيت من حل أفضل وأبسط بكثير - سنجعل FixedNameTestMethodBuilder إستراتيجية افتراضية في v4 (الإصدار الرئيسي التالي) الذي سيتم إصداره في الشهر أو الشهرين القادمين. تمت الموافقة على PR المناسب

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

أعتقد أنني انتهيت من حل أفضل وأبسط بكثير - سنجعل FixedNameTestMethodBuilder استراتيجية افتراضية في v4 (إصدارنا الرئيسي التالي) الذي سيصدر في الشهر أو الشهرين القادمين.

سيعمل بشكل رائع بالنسبة لي :) أنا سعيد! شكرا على كل ما تبذلونه من جهد.

رائع 😉 شكرًا لك مرة أخرى على ردودك وتعاونك 👍

أنا أغلق هذا لأنه لا توجد إجراءات مطلوبة أكثر من كلا الجانبين.

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