🧑🏿‍🤝‍🧑🏽 Ⓜ️ 👼🏽 यूनिट फेयरी मैजिक फेयरी: डीएसएल इन सी # ♣️ 🐊 👛

यह कितनी बार हुआ है कि जब आप एक कार्यशील इकाई परीक्षण लिखते हैं, तो आप इसके कोड को देखते हैं, और क्या यह ... बुरा है? और आप ऐसा सोचते हैं: "यह एक परीक्षा है, इसे ऐसे ही छोड़ दें ..."। नहीं,% उपयोगकर्ता नाम% है, इसलिए इसे न छोड़ें। टेस्ट सिस्टम का एक महत्वपूर्ण हिस्सा है जो कोड समर्थन प्रदान करता है, और यह बहुत महत्वपूर्ण है कि यह हिस्सा भी समर्थित है। दुर्भाग्य से, हमारे पास यह सुनिश्चित करने के लिए कई तरीके नहीं हैं (हम परीक्षणों के लिए परीक्षण नहीं लिखेंगे), लेकिन अभी भी एक जोड़े हैं।

हमारे डोडो देवस्कूल डेवलपर स्कूल में, हम दूसरों के बीच, एक अच्छे परीक्षण के लिए निम्न मापदंड पर प्रकाश डालते हैं:

reproducibility: एक ही कोड और इनपुट पर परीक्षण चलाने से हमेशा एक ही परिणाम होता है;
फोकस: परीक्षण गिरने के लिए केवल एक कारण होना चाहिए;
समझ: अच्छी तरह से, यहाँ यह स्पष्ट है। :)

इन कसौटियों के संदर्भ में आपको ऐसी परीक्षा कैसी लगती है?

[Fact] public void AcceptOrder_Successful() { var ingredient1 = new Ingredient("Ingredient1"); var ingredient2 = new Ingredient("Ingredient2"); var ingredient3 = new Ingredient("Ingredient3"); var order = new Order(DateTime.Now); var product1 = new Product("Pizza1"); product1.AddIngredient(ingredient1); product1.AddIngredient(ingredient2); var orderLine1 = new OrderLine(product1, 1, 500); order.AddLine(orderLine1); var product2 = new Product("Pizza2"); product2.AddIngredient(ingredient1); product2.AddIngredient(ingredient3); var orderLine2 = new OrderLine(product2, 1, 650); order.AddLine(orderLine2); var orderRepositoryMock = new Mock<IOrderRepository>(); var ingredientsRepositoryMock = new Mock<IIngredientRepository>(); var service = new PizzeriaService(orderRepositoryMock.Object, ingredientsRepositoryMock.Object); service.AcceptOrder(order); orderRepositoryMock.Verify(r => r.Add(order), Times.Once); ingredientsRepositoryMock.Verify(r => r.ReserveIngredients(order), Times.Once); }

मेरे लिए - बहुत बुरा।

यह समझ से बाहर है: उदाहरण के लिए, मैं व्यवस्था, अधिनियम और मुखर ब्लॉक भी आवंटित नहीं कर सकता।

अयोग्य: DateTime.Now संपत्ति का उपयोग किया जाता है। और अंत में, यह खुला हुआ है, क्योंकि गिरावट के 2 कारण हैं: दो रिपॉजिटरी के तरीकों पर कॉल की जाँच की जाती है।

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

यदि आप सहमति से परीक्षा का नाम नहीं दे सकते हैं, तो परीक्षण में कुछ गड़बड़ है।

चूंकि परीक्षण समझ से बाहर है, आइए आपको बताते हैं कि इसमें क्या हो रहा है:

सामग्री बनाई जाती है।
अवयवों से, उत्पाद (पिज्जा) बनाए जाते हैं।
उत्पादों से एक ऑर्डर बनाया जाता है।
एक सेवा बनाई जाती है जिसके लिए रिपॉजिटरी गीली होती है।
आदेश सेवा की AcceptOrder विधि को पारित किया जाता है।
यह सत्यापित किया जाता है कि संबंधित रिपॉजिटरी के Add और ReserveIngredients के तरीकों को बुलाया गया है।

तो हम इस परीक्षा को कैसे बेहतर बनाते हैं? आपको केवल परीक्षण के शरीर में छोड़ने की कोशिश करने की आवश्यकता है जो वास्तव में महत्वपूर्ण है। और उसके लिए, मार्टिन फाउलर और रेबेका पार्सन्स जैसे स्मार्ट लोग DSL (डोमेन विशिष्ट भाषा) के साथ आए। यहां मैं उन डीएसएल पैटर्न के बारे में बात करूंगा जिनका उपयोग हम डोडो में करते हैं ताकि हमारी इकाई परीक्षण नरम और रेशमी हो सकें, और डेवलपर्स हर दिन आत्मविश्वास महसूस करें।

योजना यह है: पहले हम इस परीक्षण को समझ में लाएँगे, फिर हम प्रतिलिपि प्रस्तुतिकरण पर काम करेंगे और इसे केंद्रित करके समाप्त करेंगे। हमने चलाई ...

सामग्री का निपटान (पूर्वनिर्धारित डोमेन ऑब्जेक्ट)

चलिए ऑर्डर क्रिएशन ब्लॉक से शुरू करते हैं। आदेश देना केंद्रीय डोमेन संस्थाओं में से एक है। यह अच्छा होगा यदि हम आदेश का वर्णन इस तरह से कर सकते हैं कि यहां तक कि वे लोग भी जो कोड लिखना नहीं जानते हैं लेकिन डोमेन लॉजिक को समझ सकते हैं कि हम किस तरह का ऑर्डर बना रहे हैं। ऐसा करने के लिए, सबसे पहले, हमें वास्तविक अवयवों, पिज्जा और अन्य डोमेन ऑब्जेक्ट्स के साथ अमूर्त "संघटक 1" और "पिज्जा 1" के उपयोग को छोड़ने की आवश्यकता है।

अनुकूलन के लिए पहला उम्मीदवार सामग्री है। उनके साथ सब कुछ सरल है: उन्हें किसी भी अनुकूलन की आवश्यकता नहीं है, बस निर्माता को एक कॉल। यह उन्हें एक अलग कंटेनर में ले जाने और उन्हें नाम देने के लिए पर्याप्त है ताकि यह डोमेन विशेषज्ञों के लिए स्पष्ट हो:

 public static class Ingredients { public static readonly Ingredient Dough = new Ingredient("Dough"); public static readonly Ingredient Pepperoni = new Ingredient("Pepperoni"); public static readonly Ingredient Mozzarella = new Ingredient("Mozzarella"); }

पूरी तरह से पागल संघटक 1, संघटक 2 और संघटक 3 के बजाय, हमें आटा, पेपरोनी और मोज़ेरेला मिला।

आमतौर पर उपयोग की जाने वाली डोमेन संस्थाओं के लिए पूर्वनिर्धारित डोमेन ऑब्जेक्ट का उपयोग करें।

उत्पादों के लिए बिल्डर

अगली डोमेन इकाई उत्पाद है। उनके साथ सब कुछ थोड़ा अधिक जटिल है: प्रत्येक उत्पाद में कई घटक होते हैं और हमें उपयोग करने से पहले उन्हें उत्पाद में जोड़ना होगा।

यहाँ, अच्छा पुराना बिल्डर पैटर्न काम आता है। यहाँ उत्पाद के लिए मेरा निर्माण संस्करण है:

 public class ProductBuilder { private Product _product; public ProductBuilder(string name) { _product = new Product(name); } public ProductBuilder Containing(Ingredient ingredient) { _product.AddIngredient(ingredient); return this; } public Product Please() { return _product; } }

इसमें एक पैरामीटर निर्मित कंस्ट्रक्टर, एक कस्टम Containing विधि और एक टर्मिनल Please विधि शामिल है। यदि आपको कोड के साथ रहना पसंद नहीं है, तो आप Please Now साथ बदल सकते हैं। बिल्डर जटिल कंस्ट्रक्टर और विधि कॉल को छुपाता है जो ऑब्जेक्ट को कॉन्फ़िगर करता है। कोड क्लीनर और अधिक समझ में आता है। एक अच्छे तरीके से, बिल्डर को ऑब्जेक्ट के निर्माण को सरल बनाना चाहिए ताकि कोड डोमेन विशेषज्ञ के पास स्पष्ट हो। यह उन वस्तुओं के लिए एक बिल्डर का उपयोग करने के लिए विशेष रूप से लायक है जिन्हें काम शुरू करने से पहले कॉन्फ़िगरेशन की आवश्यकता होती है।

उत्पाद बिल्डर आपको डिज़ाइन बनाने की अनुमति देगा जैसे:

 var pepperoni = new ProductBuilder("Pepperoni") .Containing(Ingredients.Dough) .Containing(Ingredients.Pepperoni) .Please();

आपको उन वस्तुओं को बनाने में मदद करता है जिन्हें अनुकूलन की आवश्यकता है भले ही कॉन्फ़िगरेशन में एक पंक्ति हो, एक बिल्डर बनाने पर विचार करें।

वस्तु ObjectMother

इस तथ्य के बावजूद कि उत्पाद का निर्माण बहुत अधिक सभ्य हो गया है, new ProductBuilder के डिजाइनर अभी भी बहुत बदसूरत दिखते हैं। ObjectMother (पिता) पैटर्न के साथ इसे ठीक करें।

पैटर्न 5 kopecks के रूप में सरल है: हम एक स्थिर वर्ग बनाते हैं और इसमें सभी बिल्डरों को इकट्ठा करते हैं।

 public static class Create { public static ProductBuilder Product(string name) => new ProductBuilder(name); }

अब आप इस तरह लिख सकते हैं:

 var pepperoni = Create.Product("Pepperoni") .Containing(Ingredients.Dough) .Containing(Ingredients.Pepperoni) .Please();

ObjectMother का आविष्कार वस्तुओं के घोषणात्मक निर्माण के लिए किया गया था। इसके अलावा, यह नए डेवलपर्स को डोमेन में पेश करने में मदद करता है, जैसा कि Create आईडीई शब्द लिखते समय आप खुद बताएंगे कि आप इस डोमेन में क्या बना सकते हैं।

हमारे कोड में, ObjectMother को कभी-कभी Not Create , लेकिन Given कहा जाता है। मुझे दोनों विकल्प पसंद हैं। यदि आपके पास कोई अन्य विचार है - टिप्पणियों में साझा करें।

घोषित रूप से ऑब्जेक्ट बनाने के लिए, ObjectMother का उपयोग करें। कोड क्लीनर हो जाएगा, और नए डेवलपर्स के लिए डोमेन में डील करना आसान हो जाएगा।

उत्पाद निकालना

यह बहुत बेहतर हो गया है, लेकिन उत्पादों को अभी भी बढ़ने के लिए जगह है। हमारे पास सीमित संख्या में उत्पाद हैं, और अवयवों की तरह, उन्हें एक अलग वर्ग में एकत्र किया जा सकता है और प्रत्येक परीक्षण के लिए प्रारंभिक नहीं:

 public static class Pizza { public static Product Pepperoni => Create.Product("Pepperoni") .Containing(Ingredients.Dough) .Containing(Ingredients.Pepperoni) .Please(); public static Product Margarita => Create.Product("Margarita") .Containing(Ingredients.Dough) .Containing(Ingredients.Mozzarella) .Please(); }

यहां मैंने कंटेनर को Products नहीं, बल्कि Pizza । यह नाम परीक्षण पढ़ने में मदद करता है। उदाहरण के लिए, यह "पेप्परोनी एक पिज्जा या सॉसेज?" जैसे सवालों को हटाने में मदद करता है।

वास्तविक डोमेन ऑब्जेक्ट्स का उपयोग करने का प्रयास करें, उत्पाद 1 जैसे विकल्प नहीं।

ऑर्डर के लिए बिल्डर (पीछे से उदाहरण)

अब हम ऑर्डर बिल्डर बनाने के लिए वर्णित पैटर्न लागू करते हैं, लेकिन अब हम बिल्डर से नहीं, बल्कि उस चीज़ से प्राप्त करते हैं जिसे हम प्राप्त करना चाहते हैं। यह है कि मैं एक आदेश कैसे बनाना चाहता हूं:

 var order = Create.Order .Dated(DateTime.Now) .With(Pizza.Pepperoni.CountOf(1).For(500)) .With(Pizza.Margarita.CountOf(1).For(650)) .Please();

हम इसे कैसे प्राप्त कर सकते हैं? हमें स्पष्ट रूप से ऑर्डर और ऑर्डर लाइन के लिए बिल्डरों की आवश्यकता है। सब कुछ आदेश के लिए बिल्डर के साथ क्रिस्टल स्पष्ट है। यहाँ यह है:

 public class OrderBuilder { private DateTime _date; private readonly List<OrderLine> _lines = new List<OrderLine>(); public OrderBuilder Dated(DateTime date) { _date = date; return this; } public OrderBuilder With(OrderLine orderLine) { _lines.Add(orderLine); return this; } public Order Please() { var order = new Order(_date); foreach (var line in _lines) { order.AddLine(line); } return order; } }

लेकिन OrderLine साथ OrderLine स्थिति अधिक दिलचस्प है: सबसे पहले, टर्मिनल कृपया विधि को यहां नहीं बुलाया गया है, और दूसरी बात, बिल्डर तक पहुंच प्रदान की जाती है न कि स्थैतिक Create और न ही बिल्डर का निर्माण। हम implicit operator का उपयोग करके पहली समस्या को हल करेंगे और हमारा बिल्डर इस तरह दिखाई देगा:

 public class OrderLineBuilder { private Product _product; private decimal _count; private decimal _price; public OrderLineBuilder Of(decimal count, Product product) { _product = product; _count = count; return this; } public OrderLineBuilder For(decimal price) { _price = price; return this; } public static implicit operator OrderLine(OrderLineBuilder b) { return new OrderLine(b._product, b._count, b._price); } }

दूसरी विधि हमें Product वर्ग के लिए एक्सटेंशन विधि को समझने में मदद करेगी:

 public static class ProductExtensions { public static OrderLineBuilder CountOf(this Product product, decimal count) { return Create.OrderLine.Of(count, product) } }

सामान्य तौर पर, एक्सटेंशन विधियां डीएसएल के महान दोस्त हैं। वे पूरी तरह से नारकीय तर्क से एक घोषणात्मक, समझने योग्य विवरण बना सकते हैं।

एक्सटेंशन विधियों का उपयोग करें। बस उनका उपयोग करें। :)

इन सभी कार्यों को करने के बाद, हमें निम्नलिखित परीक्षण कोड मिला:

 [Fact] public void AcceptOrder_Successful() { var order = Create.Order .Dated(DateTime.Now) .With(Pizza.Pepperoni.CountOf(1).For(500)) .With(Pizza.Margarita.CountOf(1).For(650)) .Please(); var orderRepositoryMock = new Mock<IOrderRepository>(); var ingredientsRepositoryMock = new Mock<IIngredientRepository>(); var service = new PizzeriaService(orderRepositoryMock.Object, ingredientsRepositoryMock.Object); service.AcceptOrder(order); orderRepositoryMock.Verify(r => r.Add(order), Times.Once); ingredientsRepositoryMock.Verify(r => r.ReserveIngredients(order), Times.Once); }

यहाँ हमने दृष्टिकोण लिया है कि हम "परी परी" कहते हैं। यह तब होता है जब आप पहली बार बेकार कोड लिखते हैं जैसा कि आप इसे देखना चाहते हैं, और फिर जो आपने डीएसएल में लिखा है उसे लपेटने का प्रयास करें। यह कार्य करने के लिए बहुत उपयोगी है - कभी-कभी आप स्वयं कल्पना नहीं कर सकते कि C # क्या सक्षम है।

कल्पना कीजिए कि एक जादुई परी आ गई है और आपको अपनी इच्छानुसार कोड लिखने की अनुमति दी गई है, और फिर डीएसएल में लिखी गई हर चीज को लपेटने का प्रयास करें।

एक सेवा बनाना (परीक्षण करने योग्य पैटर्न)

आदेश के साथ अब सब कुछ कमोबेश खराब है। रिपॉजिटरी के मोका से निपटने का समय आ गया है। यहां यह कहने योग्य है कि परीक्षण स्वयं, जिसे हम विचार कर रहे हैं, व्यवहार के लिए एक परीक्षा है। व्यवहार परीक्षण दृढ़ता से तरीकों के कार्यान्वयन के साथ जुड़े हुए हैं, और यदि यह संभव है कि इस तरह के परीक्षण नहीं लिखे जाएं, तो बेहतर है कि नहीं। हालाँकि, कभी-कभी वे उपयोगी होते हैं, और कभी-कभी, आप उनके बिना बिल्कुल नहीं कर सकते। निम्न तकनीक व्यवहार के लिए बिल्कुल परीक्षण लिखने में मदद करती है, और यदि आपको अचानक पता चलता है कि आप इसका उपयोग करना चाहते हैं, तो पहले इस बारे में सोचें कि क्या आप परीक्षणों को इस तरह से फिर से लिख सकते हैं कि वे राज्य की जाँच करें, व्यवहार की नहीं।

इसलिए, मैं यह सुनिश्चित करना चाहता हूं कि मेरी परीक्षा पद्धति में एक भी मोक नहीं है। ऐसा करने के लिए, मैं PizzeriaService सर्विस के लिए एक रैपर PizzeriaService जिसमें मैं उन सभी तर्कों को कूटबद्ध करता PizzeriaService जो विधि कॉल की जाँच करते हैं:

 public class PizzeriaServiceTestable : PizzeriaService { private readonly Mock<IOrderRepository> _orderRepositoryMock; private readonly Mock<IIngredientRepository> _ingredientRepositoryMock; public PizzeriaServiceTestable(Mock<IOrderRepository> orderRepositoryMock, Mock<IIngredientRepository> ingredientRepositoryMock) : base(orderRepositoryMock.Object, ingredientRepositoryMock.Object) { _orderRepositoryMock = orderRepositoryMock; _ingredientRepositoryMock = ingredientRepositoryMock; } public void VerifyAddWasCalledWith(Order order) { _orderRepositoryMock.Verify(r => r.Add(order), Times.Once); } public void VerifyReserveIngredientsWasCalledWith(Order order) { _ingredientRepositoryMock.Verify(r => r.ReserveIngredients(order), Times.Once); } }

यह वर्ग हमें विधि कॉल की जांच करने की अनुमति देगा, लेकिन हमें अभी भी इसे किसी तरह बनाने की आवश्यकता है। ऐसा करने के लिए, हम उस बिल्डर का उपयोग करेंगे जिसे हम पहले से जानते हैं:

 public class PizzeriaServiceBuilder { public PizzeriaServiceTestable Please() { var orderRepositoryMock = new Mock<IOrderRepository>(); var ingredientsRepositoryMock = new Mock<IIngredientRepository>(); return new PizzeriaServiceTestable(orderRepositoryMock, ingredientsRepositoryMock); } }

फिलहाल, हमारी परीक्षा पद्धति इस प्रकार है:

 [Fact] public void AcceptOrder_Successful() { var order = Create.Order .Dated(DateTime.Now) .With(Pizza.Pepperoni.CountOf(1).For(500)) .With(Pizza.Margarita.CountOf(1).For(650)) .Please(); var service = Create.PizzeriaService.Please(); service.AcceptOrder(order); service.VerifyAddWasCalledWith(order); service.VerifyReserveIngredientsWasCalledWith(order); }

परीक्षण विधि कॉल केवल परीक्षण योग्य वर्ग का उपयोग करने का एकमात्र कारण नहीं है। यहाँ, उदाहरण के लिए, यहाँ हमारे दीमा पावलोव ने विरासत कोड के जटिल रीफैक्टरिंग के लिए इसका उपयोग किया है।

परीक्षण योग्य सबसे कठिन मामलों में स्थिति को बचाने में सक्षम है। व्यवहार परीक्षण के लिए, यह बदसूरत कॉल चेक को सुंदर तरीकों में लपेटने में मदद करता है।

इस क्षण में, हम परीक्षण की समझ को समझने के लिए समाप्त हो गए। यह इसे प्रजनन योग्य और केंद्रित बनाने के लिए बनी हुई है।

रेप्रोड्यूसबिलिटी (शाब्दिक विस्तार)

लिटरल एक्सटेंशन पैटर्न सीधे तौर पर प्रजनन क्षमता से संबंधित नहीं है, लेकिन इससे हमें मदद मिलेगी। फिलहाल हमारी समस्या यह है कि हम DateTime.Now दिनांक का उपयोग आदेश दिनांक के रूप में करते हैं। यदि अचानक कुछ तारीख से शुरू होता है, तो ऑर्डर स्वीकृति का तर्क बदल जाता है, तो हमारे व्यापार तर्क में हमें कम से कम कुछ समय के लिए ऑर्डर स्वीकृति के 2 तर्क का समर्थन करना होगा, if (order.Date > edgeDate) जैसे आदेश। if (order.Date > edgeDate) जाँच करके उन्हें अलग करना। इस मामले में, हमारे परीक्षण में गिरावट का मौका है जब सिस्टम की तारीख सीमा से गुजरती है। हां, हम जल्दी से इसे ठीक कर देंगे, और यहां तक कि दो में से एक परीक्षण करेंगे: एक सीमा तिथि से पहले तर्क की जांच करेगा, और दूसरे के बाद। फिर भी, ऐसी स्थितियों से बचने के लिए बेहतर है और तुरंत सभी इनपुट डेटा को स्थिर बनाएं।

"और DSL कहाँ है?" - आप पूछें। तथ्य यह है कि एक्सटेंशन विधियों के माध्यम से परीक्षणों में तिथियां दर्ज करना सुविधाजनक है, उदाहरण के लिए 3.May(2019) । रिकॉर्डिंग का यह रूप न केवल डेवलपर्स के लिए, बल्कि व्यवसाय के लिए भी समझा जा सकता है। ऐसा करने के लिए, बस एक ऐसी स्टैटिक क्लास बनाएं

 public static class DateConstructionExtensions { public static DateTime May(this int day, int year) => new DateTime(year, 5, day); }

स्वाभाविक रूप से, तारीखें इस पैटर्न का उपयोग करने वाली एकमात्र चीज नहीं हैं। उदाहरण के लिए, यदि हमने उत्पादों की संरचना में अवयवों की मात्रा का परिचय दिया, तो हम कुछ लिख सकते हैं जैसे 42.Grams("flour") ।

मात्रात्मक वस्तुओं और तिथियों को आसानी से परिचित विस्तार विधियों के माध्यम से बनाया जाता है।

फोकस

परीक्षणों को ध्यान में रखना क्यों महत्वपूर्ण है? तथ्य यह है कि केंद्रित परीक्षणों को बनाए रखना आसान है, लेकिन उन्हें अभी भी समर्थन करना है। उदाहरण के लिए, उन्हें कोड बदलते समय बदलना होगा और पुरानी सुविधाओं को देखने पर हटा दिया जाएगा। यदि परीक्षणों पर ध्यान केंद्रित नहीं किया जाता है, तो तर्क बदलते समय, आपको बड़े परीक्षणों को समझने की आवश्यकता होगी, और उनमें से परीक्षण की गई कार्यक्षमता के टुकड़े काट दें। यदि परीक्षण केंद्रित हैं और उनके नाम स्पष्ट हैं, तो आपको केवल अप्रचलित परीक्षणों को हटाने और नए लिखने की आवश्यकता है। यदि परीक्षणों में एक अच्छा डीएसएल है, तो यह बिल्कुल समस्या नहीं है।

इसलिए, हमने DSL लिखने के बाद, हमें इस परीक्षण को 2 परीक्षणों में विभाजित करके ध्यान केंद्रित करने का अवसर दिया:

 [Fact] public void WhenAcceptOrder_AddIsCalled() { var order = Create.Order .Dated(3.May(2019)) .With(Pizza.Pepperoni.CountOf(1).For(500)) .With(Pizza.Margarita.CountOf(1).For(650)) .Please(); var service = Create.PizzeriaService.Please(); service.AcceptOrder(order); service.VerifyAddWasCalledWith(order); } [Fact] public void WhenAcceptOrder_ReserveIngredientsIsCalled() { var order = Create.Order .Dated(3.May(2019)) .With(Pizza.Pepperoni.CountOf(1).For(500)) .With(Pizza.Margarita.CountOf(1).For(650)) .Please(); var service = Create.PizzeriaService.Please(); service.AcceptOrder(order); service.VerifyReserveIngredientsWasCalledWith(order); }

दोनों परीक्षण छोटे, स्पष्ट, प्रतिलिपि प्रस्तुत करने योग्य और केंद्रित थे।

कृपया ध्यान दें कि अब परीक्षणों के नाम उस उद्देश्य को दर्शाते हैं जिसके लिए वे लिखे गए थे और अब कोई भी डेवलपर जो मेरी परियोजना में आया था, समझ जाएगा कि प्रत्येक परीक्षण क्यों लिखा गया था और इस परीक्षण में क्या होता है।

परीक्षणों का ध्यान उन्हें समर्थित बनाता है। एक अच्छी परीक्षा पर ध्यान केंद्रित करना चाहिए।

और अब, मैं आपको पहले से ही चिल्लाते हुए सुन सकता हूं, "यूरा, क्या बकवास कर रहे हैं? हमने परीक्षण के एक जोड़े को सुंदर बनाने के लिए एक लाख कोड लिखा है? " हाँ, बिल्कुल। जबकि हमारे पास केवल कुछ परीक्षण हैं, यह डीएसएल में निवेश करने और इन परीक्षणों को समझने योग्य बनाता है। एक बार जब आप डीएसएल लिखते हैं, तो आपको गुड़ियों का गुच्छा मिलता है:

नए परीक्षण लिखना आसान हो जाता है। इकाई परीक्षण के लिए खुद को 2 घंटे तक सेट करने की आवश्यकता नहीं है, बस ले और लिखो।
टेस्ट समझने और पढ़ने योग्य हो जाते हैं। परीक्षण देखने वाला कोई भी डेवलपर समझता है कि यह क्यों लिखा गया था और यह क्या जाँच करता है।
नए डेवलपर्स के लिए परीक्षण (और शायद डोमेन में) में शामिल होने की सीमा कम हो गई है। उदाहरण के लिए, ObjectMother के माध्यम से, आप आसानी से यह पता लगा सकते हैं कि डोमेन में क्या ऑब्जेक्ट बनाए जा सकते हैं।
और अंत में, परीक्षणों के साथ काम करना अच्छा है, और परिणामस्वरूप, कोड अधिक समर्थित हो जाता है।

नमूना स्रोत कोड और परीक्षण यहां उपलब्ध हैं ।

यूनिट फेयरी मैजिक फेयरी: डीएसएल इन सी #