متى يمكنني استخدام سمة testfixturesetup بدلاً من مُنشئ افتراضي؟

StackOverflow https://stackoverflow.com/questions/212718

  •  03-07-2019
  •  | 
  •  

سؤال

لا تخبرني وثائق NUNIT بموعد استخدام طريقة مع أ TestFixtureSetup ومتى القيام بالإعداد في المنشئ.

public class MyTest
{
    private MyClass myClass;

    public MyTest()
    {
        myClass = new MyClass();
    }

    [TestFixtureSetUp]
    public void Init()
    {
        myClass = new MyClass();
    }
}

هل هناك أي ممارسات جيدة/سيئة حول TestFixtureSetup مقابل مُنشئ افتراضي أم أنه لا يوجد فرق؟

هل كانت مفيدة؟

المحلول

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

بالنسبة إلى Nunit ، كانت أفضل ممارسات في هذه الحالة هي استخدام TestFixtureSetUp, TestFixtureTearDown, SetUp, ، و TearDown الطرق كما هو موضح في الوثائق.

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

نصائح أخرى

لماذا تحتاج إلى استخدام مُنشئ في فصول الاختبار الخاصة بك؟

أنا أستعمل [SetUp] و [TearDown] طرق ملحوظة لتنفيذ الكود قبل وبعد كل اختبار ، وبالمثل [TestFixtureSetUp] و [TestFixtureTearDown] تم إجراء طرق ملحوظة لتنفيذ الكود مرة واحدة فقط قبل وبعد كل اختبار في المباراة.

أعتقد أنه من المحتمل أن تحل محل [TestFixtureSetUp] بالنسبة إلى مُنشئ (على الرغم من أنني لم أحاول) ، ولكن يبدو أن هذا ينطلق فقط من الاتفاقية الواضحة التي توفرها الأساليب المحددة.

شيء واحد لا يمكنك فعله [TestFixtureSetup] يمكنك القيام به في المُنشئ هو تلقي معلمات من [TestFixture] .

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

[TestFixture("System.Data.SqlClient",
  "Server=(local)\\SQLEXPRESS;Initial Catalog=MyTestDatabase;Integrated Security=True;Pooling=False"))]
[TestFixture("System.Data.SQLite", "Data Source=MyTestDatabase.s3db")])]
internal class MyDataAccessLayerIntegrationTests
{
    MyDataAccessLayerIntegrationTests(
        string dataProvider,
        string connectionString)
    {
        ...
    }
}

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

تفضيلي هو استخدام المُنشئين ، للاستفادة من الكلمة الرئيسية القراءة لضمان تعزيز متغيرات الأعضاء.

هناك اختلاف بين المنشئ والطريقة المميزة بـ [TestFixtureSetUp] ينسب. وفقا لوثائق نونيت:

من المستحسن ألا يكون للمنشئ أي آثار جانبية ، لأن NUNIT قد يبني الكائن عدة مرات في سياق الجلسة.

لذلك إذا كان لديك أي تهيئة باهظة الثمن ، فمن الأفضل استخدامها TestFixtureSetUp.

[TestFixtureSetUp] و [TestFixtureTearDown] هي لفئة اختبار كاملة. يعمل مرة واحدة فقط.

[SetUp] و [TearDown] هي لكل طريقة اختبار (اختبار). يدير لكل اختبار.

هناك اختلاف مهم بين المنشئ و testfixturesetup هو أنه في NUNIT 2 على الأقل ، يتم تنفيذ رمز المنشئ فعليًا على تعداد الاختبار ، وليس فقط اختبار التشغيل ، لذا فأنت في الأساس تريد الحد من رمز CTOR فقط للاستعداد القراءة ، أي المعلمة ، أي القيم. أي شيء يسبب الآثار الجانبية أو يقوم بأي عمل فعلي يحتاج إما إلى ملفوف في كسول أو يتم في testfixturesetup / onetimesetup. لذلك ، يمكنك التفكير في المُنشئ كمكان فقط لتكوين الاختبار. في حين أن TestFixTuresetup هو المكان الذي تتم فيه تهيئة تركيبات الاختبار ، يتم تهيئة الحالة الأولية المطلوبة للنظام قبل إجراء الاختبارات.

أعتقد أن لدي إجابة سلبية جيدة - سبب استخدام مُنشئ بدلاً من السمة هو عندما يكون لديك ميراث بين فئات الاختبار.

طريقة واحدة فقط مشروح مع [TestFixtureSetup] سيتم استدعاؤه (على فئة الخرسانة فقط) ، لكن المهيئات الأخرى لن تكون. في هذه الحالة ، أفضل وضع التهيئة في المنشئ ، الذي يحتوي على دلالات محددة جيدًا للميراث :)

المنشئ و SetUp يتم استخدام الطرق بشكل مختلف:
يتم تشغيل المنشئ مرة واحدة فقط.
ومع ذلك ، فإن SetUp يتم تشغيل الطرق عدة مرات ، قبل تنفيذ كل حالة اختبار.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top