हम BDD शैली में NUnit परीक्षण बनाते हैं

एक शांत शुक्रवार की रात को, मैंने लागू तर्क का परीक्षण करके अपने कार्य दिवस को समाप्त कर दिया। रॉय की सिफारिश के अनुसार, मैंने सावधानीपूर्वक परीक्षणों के नामों का चयन किया। और अचानक मुझे एहसास हुआ कि परीक्षण का समझने योग्य विस्तारित नाम एक भयानक राक्षस में बदल गया और पूरी तरह से समझ में नहीं आया। इसके अलावा, स्क्रीन पर 120 वर्णों में फिट होना बंद हो गया।

और इसलिए मुझे याद आया कि कहीं न कहीं व्यवहार-विकास की धारणा मेरे सामने आई थी और इस शैली में लिखे गए परीक्षण बहुत अधिक पठनीय और समझने योग्य थे। "Nunit bdd" के अनुरोध पर Google बहुत कम परिणाम देता है, लेकिन इस पोस्ट ने मुझे एक दिलचस्प विचार के लिए प्रेरित किया। दिए गए और जब तरीके स्थिति का स्पष्ट विवरण नहीं देते हैं, तो बहुत कम स्पष्ट रूप से एक से अधिक स्थिति का वर्णन करते हैं। मैंने समाधान को थोड़ा संशोधित करने का फैसला किया।

यहाँ, वैसे, परीक्षण का बहुत नाम है:
CreateMonthlyPaymentInvoice_WhenCustomerIsRegularCompany_ShouldCreateMonthlyUsageInvoiceWithoutBankFee।
खौफनाक है, है ना?


मैंने लेख में वर्णित दृष्टिकोण में काफी मामूली बदलाव किए। दिए गए, और जब विशेषताओं और इन विशेषताओं के साथ चिह्नित विधियों को कॉल करने का तर्क जोड़ा गया।

namespace NUnit.Specification { public abstract class SpecificationBase { [TestFixtureSetUp] public void SetUp() { Setup(); Given(); When(); } public virtual void Setup() { } private void Given() { IEnumerable<MethodInfo> publicMethods = this.GetType().GetMethods(); publicMethods.Where(m => m.GetCustomAttributes(typeof(GivenAttribute), false).Count() != 0) .ToList() .ForEach(m => m.Invoke(this, new object[0])); publicMethods.Where(m => m.GetCustomAttributes(typeof(AndAttribute), false).Count() != 0) .ToList() .ForEach(m => m.Invoke(this, new object[0])); } private void When() { this.GetType() .GetMethods() .Where(m => m.GetCustomAttributes(typeof(WhenAttribute), false).Count() != 0) .ToList() .ForEach(m => m.Invoke(this, new object[0])); } [TestFixtureTearDown] public void TearDown() { Teardown(); } public virtual void Teardown() { } } public class SpecificationAttribute : TestFixtureAttribute { } public class GivenAttribute : Attribute { } public class AndAttribute : Attribute { } public class WhenAttribute : Attribute { } public class ThenAttribute : TestAttribute { } } 

अब परीक्षण बहुत अधिक पठनीय और लचीले हो गए हैं।

  [Specification] public class Create_invoice_for_regular_customer : SpecificationBase { private Customer _customer; private List<Transaction> _transactions; private Document _invoice; public override void Setup() { // General context setup like DateTimeProvider.Current = new Mock<DateTimeProvider>().Object; Mock.Get(DateTimeProvider.Current).Setup(m => m.GetCurrentTime()).Returns(new DateTime(2012, 10, 26)); } [Given] public void Customer_is_regular_company() { _customer= new Customer () { Name = "Jedi" }; } [And] public void Set_of_transactions_representing_monthly_usage() { _transactions = new[] { new Transaction() { Amount = 25 }, new Transaction() { Amount = 16 }, new Transaction() { Amount = 32 }, }.ToList(); } [When] public void Creating_monthly_usage_document() { _invoice = DocumentCreator.CreateMonthlyPaymentInvoice(_customer, _transactions); } [Then] public void Document_should_contain_transactions_and_not_contain_bank_fee() { var expectedInvoice = new ExpectedInvoice(); Assert.That(_invoice, Is.EqualTo(expectedInvoice)); } public override void Teardown() { DateTimeProvider.Current = new DateTimeProvider(); } } 

अगर ऐसी कोई बात उपयोगी साबित होती है, तो मैं इसके लिए NuGet पैकेज बनाने की कोशिश करूंगा।
आपका ध्यान उन लोगों के लिए धन्यवाद जो पढ़ते हैं और एक अच्छा सप्ताहांत है।

UPD: गलती से एक वीडियो प्रदर्शन देखने से, पराक्रमी मूस ने पाया कि यह विचार मूल रूप से Fohjin.DDD.Example उदाहरण में लागू किया गया था। थोड़ा अलग, लेकिन सार एक ही है। मैं एक ही कक्षा में कई गिवेन / और विशेषताओं का उपयोग कर सकता हूं।