متى يمكنني استخدام سمة testfixturesetup بدلاً من مُنشئ افتراضي؟
-
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
يتم تشغيل الطرق عدة مرات ، قبل تنفيذ كل حالة اختبار.