एक उदाहरण के रूप में .Net का उपयोग करते हुए डीएसएल पर जोर दें

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

विज्ञान में, परीक्षण सिस्टम प्रलेखन हैं। अच्छी तरह से लिखित परीक्षण यह स्पष्ट करते हैं कि सिस्टम कैसे काम करता है, यह कैसे व्यवहार करता है, और यह सब सिस्टम के व्यवहार के लिए तैयार विनिर्देश के रूप में पढ़ा जाना चाहिए। यानी आदर्श रूप से, एक सुसंगत और समझने योग्य पाठ प्राप्त किया जाना चाहिए। यह एक आदर्श है कि परीक्षण विधियां धीरे-धीरे आ रही हैं, इकाई परीक्षण से शुरू होती हैं और सबसे व्यवहार / स्वीकृति परीक्षण में खुद को प्रकट करती हैं, जब परीक्षण खुद को पहले से ही व्यवसाय की भाषा में लिखा जाता है (इस बिंदु पर हम फिटनेस को याद करते हैं)।

परीक्षण लिखते समय, आपको कोड और कक्षाओं की तर्ज पर कंजूसी नहीं करनी चाहिए, केवल उन्हें सही ढंग से संरचना करना महत्वपूर्ण है। मेरा मानना ​​है कि यह काफी सामान्य हो सकता है कि आपके परीक्षण वर्ग में केवल एक ही परीक्षण विधि शामिल है - शर्मीली न हों, यह 20 स्क्रीन वाली कक्षाओं की तुलना में बहुत बेहतर है। HD स्क्रीन।

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

निस्तारण न करने के लिए, मैं तुरंत आपको बताऊंगा कि परीक्षणों को बेहतर बनाने के लिए मुख्य कदम क्या हैं:

• परीक्षण की जाने वाली मुख्य विधि के अनुसार परीक्षण फाइलों को नाम दें।
• संभव के रूप में संक्षिप्त तरीके बनाने के लिए वस्तुओं को बनाने के लिए डीएसएल का उपयोग करें।
• "एक परीक्षण विधि - एक जोर" की शैली में परीक्षण लिखने की कोशिश करें।
• परीक्षण के अंदरूनी हिस्सों की संरचना करें।
• Assert DSL बनाएँ और उपयोग करें।

मुझे लगता है कि सूचीबद्ध अंकों में से अधिकांश के लिए समाचार नहीं हैं, और उनमें से लगभग सभी वास्तविक विकास में उपयोग किए जाते हैं।



एक व्यापक अर्थ में, यह व्यवस्था अधिनियम के प्रतिमान में फिट बैठता है, जो बताता है कि परीक्षण, कार्रवाई और सत्यापन की तैयारी स्पष्ट रूप से प्रतिष्ठित होनी चाहिए। इस मामले में, यह पता चलता है कि प्रत्येक परीक्षण वर्ग परीक्षण के लिए विशिष्ट तैयारी का वर्णन करेगा। आदर्श रूप से, SetUp में या FixtureSetUp में, अधिनियम सेट किया जाएगा और परीक्षणों में परिणाम पहले से ही जांचा जाएगा - Assert।

इसे एक उदाहरण के साथ दिखाना सबसे अच्छा है।

आइए हमारे पास समुद्री डाकू वर्ग है, जो खेल में एक समुद्री डाकू के कार्यों और क्षमताओं का कार्यान्वयन है। एक समुद्री डाकू मैदान के चारों ओर घूम सकता है, सोना ले सकता है और छोड़ सकता है, लड़ सकता है, तैर सकता है, मार सकता है और मर सकता है। बहुत सी चीजें वह कर सकता है और सभी परीक्षणों को एक फाइल में बदलना और क्षेत्रों द्वारा परिसीमन परीक्षण करना गलत होगा। उदाहरण के लिए कुछ परीक्षण कक्षाएं करना बेहतर है:

• PirateMovementTests
• PirateAndGoldTests
• PirateDefaultSettingsTests
• PirateActionTests

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

• WhenCreateField
• WhenCreatePlayableField
• WhenGenerateShips

जिसके बाद कक्षा के अंदर परीक्षण निम्नानुसार हैं:

• MaxSizeShouldBeDefined
• ShouldGenerateSeaOnBorder
• ShouldGenerateShips

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

• PirateShouldLostGoldIfHeKilled
• ActionSurrenderShouldSendPirateOnShip

उस स्थिति में जब हम टेस्ट क्लास को शब्द के साथ नाम दे सकते हैं, यह अरेंज एक्ट एस्टर पर एक शुद्ध उदाहरण है। उदाहरण के लिए:

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

एक उदाहरण:

[TestFixture] public class WhenCreateField { private Field field; private TestEmptyRules rule; [TestFixtureSetUp] public void ClassInit() { // Arrange, Act rule = new TestEmptyRules(); field = rule.Field; } [Test] public void MaxSizeShouldBeDefined() { //Assert Position.MaxColumn.ShouldBeEqual(rule.Size); Position.MaxRow.ShouldBeEqual(rule.Size); } [Test] public void FieldShouldBeCreated() { //Assert field.ShouldBeNotNull(); } [Test] public void ItShouldBeGrassByDefault() { //Assert field.GetPlayableArea() .ShouldContain() .OnlyCellsOf(CellType.Grass); } … } 

सभी तैयारी परीक्षण वर्ग के प्रारंभ में की गई थी, और उसके बाद ही जाँच की जाती है।

एक परीक्षा - एक परीक्षा। यह ऊपर के उदाहरणों में देखा जा सकता है। यह तुरंत स्पष्ट हो जाता है कि परीक्षण क्या और कैसे किया गया है और आखिर में क्या होना चाहिए। अक्सर यह एक मौजूदा परीक्षा में एस्टर को जोड़ने के लिए लुभाता है - इसे हमारे लिए "एड बन्नी" कहा जाता है, इसलिए "बन्नीज़" तब बहुत आस-पास आ सकते हैं, क्योंकि वे मन को शर्मिंदा कर देंगे और अतिरिक्त समय पर परीक्षण करने के बाद चुरा लेंगे।

अगला, परीक्षणों की संरचना बहुत महत्वपूर्ण है। की तुलना करें:

 [Test] public void HeMayKillFoes() { var airplaneCell = new AirplaneCell(4, 5); var player = Black.Pirate; var foe = Red.Pirate; airplaneCell.PirateComing(foe); airplaneCell.PirateComing(player); airplaneCell.Pirates.ShouldContain().Exact(player); } [Test] public void HeMayKillFoes() { //Arrange var airplaneCell = new AirplaneCell(4, 5); var player = Black.Pirate; var foe = Red.Pirate; airplaneCell.PirateComing(foe); //Act airplaneCell.PirateComing(player); //Assert airplaneCell.Pirates.ShouldContain().Exact(player); } 

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

एक और उदाहरण:

  [Test] public void AtSecondTimeHeCanNotTransferToShip() { //Arrange var airplaneCell = new AirplaneCell(4, 5); var pirate = Black.Pirate; airplaneCell.PirateComing(pirate); //Act airplaneCell.Transfer(); airplaneCell.PirateComing(pirate); airplaneCell.Transfer(); //Assert pirate.State.ShouldBeEqual(PlayerState.Free); } 

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

अब मुख्य बिंदु, जो सबसे चौकस और लेखन परीक्षण कामरेड ने पहले ही देखा है। परीक्षणों में, कोई स्पष्ट मुखर निर्माण नहीं है।

ईमानदारी से, मुझे यह दृष्टिकोण बहुत अधिक पसंद है, क्योंकि पहला आवेग उस संपत्ति को लिखना है जिसे जांचने की आवश्यकता है । तब आप पहले से ही समझते हैं कि आपको वांछित एस्टर दर्ज करने की आवश्यकता है, जिस पर मैंने InteliSense के लिए शॉर्टकट लटकाए थे। उदाहरण के लिए, Assert.AreEqual / Assert.That ($ वास्तविक $, Is.qualTo ($ अपेक्षित $)) के लिए एएई था, अर्थात इस संयोजन को टाइप किया, टैब को दबाया और कोड में पहले से ही एक टेम्पलेट है। लेकिन यह असुविधाजनक है, ReSharper को कॉन्फ़िगर करना आवश्यक था, याद रखें कि मुखर पहले आता है।

विस्तार विधियों को लिखने और उपयोग करने की दृष्टि से भाषा की क्षमता का उपयोग करना अधिक सुविधाजनक है। इस प्रकार, आपके पास सभी डेवलपर्स के लिए हमेशा एक संकेत होगा, चाहे वे ReSharper या CodeAssist का उपयोग करें, या किसी अन्य सिस्टम का।



ऊपर दिए गए चित्रण में, आप देख सकते हैं कि कोड एक सहज, अर्थ स्तर पर लिखा गया है। पहला आवेग परीक्षण के लिए एक मूल्य लिखना है, फिर हम इस बारे में सोचते हैं कि इसकी तुलना कैसे और किसके साथ की जाए, और अंतिम चरण वांछित मूल्य को रिकॉर्ड करना है। कृपया ध्यान दें कि IntelliSense आपको बताता है कि किस प्रकार के अपेक्षित मूल्य को जांचना है।



यह चित्रण nUnit के लिए सत्यापन लिखने के लिए एक मानक दृष्टिकोण दिखाता है। याद रखें कि Assert.That उपयोगिता कोड पहले आता है। सत्यापन के लिए मान लिखते समय, IntelliSense हमेशा मदद नहीं करता है। चित्रण ड्रॉप-डाउन सूची में किसी भी आइटम को स्क्रॉल किए बिना वास्तविक कार्य दिखाता है। सत्यापन के लिए मूल्य लिखने के बाद, फिर से, आपको सेवा शब्द को "याद" करने की आवश्यकता है, सत्यापन के प्रकार को लिखें, और जब आप अपेक्षित मूल्य दर्ज करते हैं तो IntelliSense शक्तिहीन होता है।

इसके बाद, दो दृष्टिकोणों की तुलना करें:

 [Test] public void FieldShouldBeCreated() { //Assert field.ShouldBeNotNull(); } [Test] public void FieldShouldBeCreated() { //Assert Assert.IsNotNull(field); } 

और दूसरा उदाहरण:

 [Test] public void MaxSizeShouldBeDefined() { // DSL Position.MaxColumn.ShouldBeEqual(rule.Size); Position.MaxRow.ShouldBeEqual(rule.Size); // nUnit Assert.That(Position.MaxColumn, Is.EqualTo(rule.Size)); Assert.That(Position.MaxRow, Is.EqualTo(rule.Size)); // MSTest Assert.AreEqual(Position.MaxColumn, rule.Size); Assert.That(Position. MaxRow, rule.Size); } 

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

परीक्षण परीक्षणों के लिए विस्तार विधियों को लिखने का एक और फायदा उनकी तार्किक संरचना हो सकती है जो डोमेन मॉडल के अनुरूप है। यह एक उदाहरण के साथ फिर से प्रदर्शित किया जाता है:

 [Test] public void ItShouldBeGrassByDefault() { //Assert field.GetPlayableArea() .ShouldContain() .OnlyCellsOf(CellType.Grass); } [Test] public void ItShouldBeGrassByDefault() { //Assert var playableArea = field.GetPlayableArea(); Assert.IsTrue(playableArea.All(cells => cells.CellType == CellType.Grass)); //or another case Assert.IsTrue(field.GetPlayableArea() .All(cells => cells.CellType == CellType.Grass)); } 

कौन सा रास्ता साफ है?

मुझे लगता है कि विशिष्ट उपयोग के लिए अपने स्वयं के टेस्ट डीएसएल को विकसित करना मुश्किल नहीं है। लेकिन एक उदाहरण के रूप में (अभी तक पॉलिश का उपयोग नहीं):

 public static CollectionAssertCases ShouldContain(this IEnumerable enumerable) { return new CollectionAssertCases(enumerable); } public class CollectionAssertCases { private readonly IEnumerable enumerable; public List AsList { get { return new List(enumerable); } } public CollectionAssertCases(IEnumerable enumerable) { this.enumerable = enumerable; } public void Elements(params T[] elements) { Assert.That(enumerable, Is.EquivalentTo(elements)); } } public static void OnlyCellsOf(this CollectionAssertCases collection, CellType cellType) { Assert.IsTrue(collection.AsList.All(c => c.CellType == cellType)); } 

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

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

 [Test] public void PiratesStateCanNotBeSetDirectly() { //Arrange var pirate = Black.Pirate; //Assert pirate.Property("State").ShouldBeReadonly(); } 

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

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

वर्णित दृष्टिकोण के प्लस में शामिल हैं:

• मानव विचार के पाठ्यक्रम में एक परीक्षण लिखने की प्रक्रिया;
• मुखर अभिव्यक्ति का संकलन करते समय संकेत में अपेक्षित डेटा के प्रकार का स्पष्ट संकेत;
• परीक्षण की पठनीयता;
• सामान्य रूप से परीक्षणों की पठनीयता।

विपक्ष द्वारा, मैं शामिल होगा:

• प्रवेश थ्रेसहोल्ड। चेकोस्लैम का उपयोग करने के लिए आवश्यक तरीकों को खोजने के लिए शुरुआती लोगों को यह बताने की आवश्यकता होगी कि चेक के लिए डीएसएल परियोजना में क्या मौजूद है और इसके निर्माण के नियम क्या हैं।