Autofixture: لا يؤدي تجميد نموذج وهمي إلى تجاوز مثيل محقون

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

السلوك الحالي

عند حقن مثيلين ملموسين ، فإن المثيل الثاني يتجاوز الأول.

عند حقن مثيل ملموس ، متبوعًا بمثيل تم الاستهزاء به ، فإن المثيل الثاني لا يتجاوز الأول.

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

سلوك متوقع

عند حقن مثيلين ملموسين ، فإن المثيل الثاني يتجاوز الأول.

عند حقن مثيل ملموس ، متبوعًا بمثيل تم الاستهزاء به ، فإن المثيل الثاني يتجاوز الأول.

مثال على السلوك المتوقع

ج #
باستخدام System.Collections.Generic ؛
باستخدام AutoFixture ؛
باستخدام AutoFixture.AutoMoq ؛
باستخدام موك ؛
باستخدام Xunit

SomeNamespace
{
اختبارات AutoFixtureTests للفئة العامة
{
[حقيقة]
// يمر، يمرر، اجتاز بنجاح
الفراغ العام should_Override previouslyInjectedString ()
{
سلسلة const test1 = "test1" ؛
سلسلة const test2 = "test2" ؛

        var fixture = new Fixture();

        fixture.Inject(test1);
        fixture.Inject(test2);

        Assert.Equal(fixture.Create<string>(), test2);
    }

    [Fact]
    // Fails
    public void Should_OverridePreviouslyInjectedInstance()
    {
        var fixture = new Fixture().Customize(new AutoMoqCustomization());

        var sut1 = new List<int>();

        fixture.Inject<IList<int>>(sut1);
        fixture.Freeze<Mock<IList<int>>>();

        var sut2 = fixture.Create<IList<int>>();

        Assert.NotSame(sut1, sut2);
    }
}

}
""

question

مصدر

charles-salmon

التعليق الأكثر فائدة

مرحبًا @ charles-salmon ،

شكرا لك على الوقت الذي قضيته في الإبلاغ عن هذا.

السلوك الذي تراقبه هو _ بالتصميم_. اسمح لي أن أشرح. 🙂

إذا نظرت إلى تطبيق طريقة Freeze<T> :

var value = fixture.Create<T>();
fixture.Inject(value);
return value;

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

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

بالنظر إلى ذلك ، لا ينبغي أن يكون مفاجئًا أن تجميد نفس النوع T كمثيل محقون ينتج عنه نفس المثيل.

الآن ، لمعالجة وجهة نظرك:

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

بالنظر إلى أن أحد التركيبات يمثل _context_ الذي يتم فيه تشغيل الاختبار ، فبالتأكيد _يمكنك _ أن يكون لديك اختبارات متعددة تشترك في نفس التركيبات ؛ ومع ذلك ، فإن هذا يأتي على حساب خلط مخاوف متعددة - وربما متضاربة -.

يلخص كتاب أنماط xUnit

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

هذا "الاصطدام" هو بالضبط ما يحدث عندما يتوقع الاختبار أن يكون كائن من النوع T مثيلًا محددًا ، بينما يتوقع اختبار آخر أن يكون T كائنًا مزيفًا .

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

ecampidoglio في ١ أغسطس ٢٠١٨

👍3

>كل التعليقات

مرحبًا @ charles-salmon ،

شكرا لك على الوقت الذي قضيته في الإبلاغ عن هذا.

السلوك الذي تراقبه هو _ بالتصميم_. اسمح لي أن أشرح. 🙂

إذا نظرت إلى تطبيق طريقة Freeze<T> :

var value = fixture.Create<T>();
fixture.Inject(value);
return value;

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

بالنظر إلى ذلك ، لا ينبغي أن يكون مفاجئًا أن تجميد نفس النوع T كمثيل محقون ينتج عنه نفس المثيل.

الآن ، لمعالجة وجهة نظرك:

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

يلخص كتاب أنماط xUnit

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