हमें परीक्षणों के जंगल से चुना गया है: हम जुड़नार से परीक्षण तक एक छोटा रास्ता बना रहे हैं

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

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

समस्या

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

//     .     //  ,      ,  //     . "   = 'customer'" - { import TestHelper._ "    < 250    -  " in { val db: Database = Database.forURL(TestConfig.generateNewUrl()) migrateDb(db) insertUser(db, id = 1, name = "test", role = "customer") insertPackage(db, id = 1, name = "test", userId = 1, status = "new") insertPackageItems(db, id = 1, packageId = 1, name = "test", price = 30) insertPackageItems(db, id = 2, packageId = 1, name = "test", price = 20) insertPackageItems(db, id = 3, packageId = 1, name = "test", price = 40) val svc = new SomeProductionLogic(db) val result = svc.calculatePrice(packageId = 1) result shouldBe 90 } "    >= 250    -  10%" in { val db: Database = Database.forURL(TestConfig.generateNewUrl()) migrateDb(db) insertUser(db, id = 1, name = "test", role = "customer") insertPackage(db, id = 1, name = "test", userId = 1, status = "new") insertPackageItems(db, id = 1, packageId = 1, name = "test", price = 100) insertPackageItems(db, id = 2, packageId = 1, name = "test", price = 120) insertPackageItems(db, id = 3, packageId = 1, name = "test", price = 130) insertBonus(db, id = 1, packageId = 1, bonusAmount = 40) val svc = new SomeProductionLogic(db) val result = svc.calculatePrice(packageId = 1) result shouldBe 279 } } "   = 'vip'" - {/*...*/} 

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

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

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

यह सब दर्द इस डिजाइन की दो गहरी समस्याओं का लक्षण है:

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

मोडलिंग

क्या हम बेहतर कर सकते हैं? (स्पॉयलर: हम कर सकते हैं।) आइए देखें कि इस परीक्षण में क्या हैं।

 val db: Database = Database.forURL(TestConfig.generateNewUrl()) migrateDb(db) insertUser(db, id = 1, name = "test", role = "customer") insertPackage(db, id = 1, name = "test", userId = 1, status = "new") insertPackageItems(db, id = 1, packageId = 1, name = "test", price = 30) insertPackageItems(db, id = 2, packageId = 1, name = "test", price = 20) insertPackageItems(db, id = 3, packageId = 1, name = "test", price = 40) 

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

हम इस स्थिरता के साथ निर्भरता तैयार करेंगे - डेटाबेस (कतार, बाहरी सेवा, आदि) भरें। तैयार निर्भरता के साथ, हम परीक्षण किए गए वर्ग (सेवाओं, मॉड्यूल, रिपॉजिटरी, आदि) को प्रारंभिक करते हैं।

 val svc = new SomeProductionLogic(db) val result = svc.calculatePrice(packageId = 1) 

कुछ इनपुट मापदंडों पर परीक्षण कोड निष्पादित करने से, हमें एक व्यापार-महत्वपूर्ण परिणाम ( आउटपुट ) प्राप्त होता है - दोनों स्पष्ट (विधि द्वारा लौटाया गया) और अंतर्निहित - कुख्यात राज्य में परिवर्तन: डेटाबेस, बाहरी सेवा, आदि।

 result shouldBe 90 

अंत में, हम यह सत्यापित करते हैं कि परिणाम वही हैं जो वे अपेक्षित थे, परीक्षण को एक या अधिक अभिकथन के साथ जोड़ दें ।

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

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

परीक्षण चल रहा है

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

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

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

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

 def runTestCycle[FX, DEP, OUT, F[_]]( fixture: FX, prepare: FX => DEP, execute: DEP => OUT, check: OUT => F[Assertion] ): F[Assertion] = //  Scala  ,   check(execute(prepare(fixture))) //        andThen: (prepare andThen execute andThen check) (fixture) 

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

 //    —     def prepareDatabase[DB](db: Database): DbFixture => DB def testInDb[DB, OUT]( fixture: DbFixture, execute: DB => OUT, check: OUT => Future[Assertion], db: Database = getDatabaseHandleFromSomewhere(), ): Future[Assertion] = runTestCycle(fixture, prepareDatabase(db), execute, check) 

सभी प्रशासनिक बारीकियों को जीवन चक्र समारोह में शामिल करके, हमें पहले से ही लिखित परीक्षा में शामिल हुए बिना परीक्षण प्रक्रिया का विस्तार करने का अवसर मिलता है। रचना के कारण, हम प्रक्रिया में कहीं भी घुसपैठ कर सकते हैं, वहां डेटा निकाल सकते हैं या जोड़ सकते हैं।

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

 def logged[T](implicit loggedT: Logged[T]): T => T = (that: T) => { //       Logged  T, //    “”  that  log(). //    - . loggedT.log(that) //    : that.log() that //    } def runTestCycle[FX, DEP, OUT, F[_]]( fixture: FX, prepare: FX => DEP, execute: DEP => OUT, check: OUT => F[Assertion] )(implicit loggedOut: Logged[OUT]): F[Assertion] = //  logged     -  execute (prepare andThen execute andThen logged andThen check) (fixture) 

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

परिणामस्वरूप, हमारा परीक्षण इस तरह दिखेगा:

 val fixture: SomeMagicalFixture = ??? //  -    def runProductionCode(id: Int): Database => Double = (db: Database) => new SomeProductionLogic(db).calculatePrice(id) def checkResult(expected: Double): Double => Future[Assertion] = (result: Double) => result shouldBe expected //    Database   testInDb "   = 'customer'" in testInDb( state = fixture, execute = runProductionCode(id = 1), check = checkResult(90) ) 

परीक्षण का शरीर उलटा हो गया है, जुड़नार और जांच अन्य परीक्षणों में पुन: उपयोग किया जा सकता है, और हम मैन्युअल रूप से डेटाबेस कहीं और तैयार नहीं करते हैं। केवल एक समस्या बनी हुई है ...

स्थिरता तैयारी

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

मान लीजिए कि हमारे परीक्षण स्टोर में एक विशिष्ट मध्यम आकार का डेटाबेस है (सादगी के लिए, 4 तालिकाओं के साथ एक उदाहरण, लेकिन वास्तव में सैकड़ों हो सकते हैं)। भाग में पृष्ठभूमि की जानकारी होती है, भाग - सीधे व्यापार, और सभी एक साथ इसे कई पूर्ण-तार्किक तार्किक संस्थाओं में जोड़ा जा सकता है। तालिकाएँ कुंजी ( विदेशी कुंजी ) द्वारा परस्पर जुड़ी होती हैं - एक Bonus इकाई बनाने के लिए, आपको Package इकाई की आवश्यकता होती है, और यह बदले में, User । और इसी तरह।

सर्किट सीमाओं और सभी प्रकार के हैक्स की स्थितियों में असंगति होती है और, परिणामस्वरूप अस्थिरता और रोमांचक डिबगिंग के घंटों का परीक्षण करने के लिए। इस कारण से, हम ईमानदारी से डेटाबेस को भर देंगे।

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

 insertUser(db, id = 1, name = "test", role = "customer") insertPackage(db, id = 1, name = "test", userId = 1, status = "new") insertPackageItems(db, id = 1, packageId = 1, name = "test", price = 30) insertPackageItems(db, id = 2, packageId = 1, name = "test", price = 20) insertPackageItems(db, id = 3, packageId = 1, name = "test", price = 40) 

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

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

 val dataTable: Seq[DataRow] = Table( ("Package ID", "Customer's role", "Item prices", "Bonus value", "Expected final price") , (1, "customer", Vector(40, 20, 30) , Vector.empty , 90.0) , (2, "customer", Vector(250) , Vector.empty , 225.0) , (3, "customer", Vector(100, 120, 30) , Vector(40) , 210.0) , (4, "customer", Vector(100, 120, 30, 100) , Vector(20, 20) , 279.0) , (5, "vip" , Vector(100, 120, 30, 100, 50), Vector(10, 20, 10), 252.0) ) 

हमारी तालिका से, हम आईडी द्वारा कुंजी - इकाई संबंध उत्पन्न करेंगे। इस मामले में, यदि इकाई दूसरे पर निर्भर करती है, तो निर्भरता के लिए एक कुंजी बनाई जाएगी। ऐसा हो सकता है कि दो अलग-अलग संस्थाएं समान पहचानकर्ता के साथ एक निर्भरता उत्पन्न करती हैं, जिससे डेटाबेस की प्राथमिक कुंजी ( प्राथमिक कुंजी ) पर प्रतिबंध का उल्लंघन हो सकता है। लेकिन इस बिंदु पर, डेटा डुप्लिकेट करने के लिए बेहद सस्ता है - चूंकि कुंजियों में केवल पहचानकर्ता होते हैं, हम उन्हें एक संग्रह में डाल सकते हैं जो डिडुप्लीकेशन प्रदान करता है, उदाहरण के लिए, Set । यदि यह अपर्याप्त हो जाता है, तो हम हमेशा जीवन चक्र फ़ंक्शन में संकलित एक अतिरिक्त फ़ंक्शन के रूप में होशियार समर्पण कर सकते हैं।

 sealed trait Key case class PackageKey(id: Int, userId: Int) extends Key case class PackageItemKey(id: Int, packageId: Int) extends Key case class UserKey(id: Int) extends Key case class BonusKey(id: Int, packageId: Int) extends Key 

हम नकली सामग्री की पीढ़ी को एक अलग वर्ग के लिए फ़ील्ड्स (उदाहरण के लिए, नाम) में सौंपते हैं। फिर, इस वर्ग की सहायता और कुंजियों को परिवर्तित करने के नियमों का सहारा लेते हुए, हम डेटाबेस में प्रविष्टि के लिए सीधे स्ट्रिंग ऑब्जेक्ट प्राप्त करते हैं।

 object SampleData { def name: String = "test name" def role: String = "customer" def price: Int = 1000 def bonusAmount: Int = 0 def status: String = "new" } sealed trait Row case class PackageRow(id: Int, name: String, userId: Int, status: String) extends Row case class PackageItemRow(id: Int, packageId: Int, name: String, price: Int) extends Row case class UserRow(id: Int, name: String, role: String) extends Row case class BonusRow(id: Int, packageId: Int, bonusAmount: Int) extends Row 

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

 def changeUserRole(userId: Int, newRole: String): Set[Row] => Set[Row] = (rows: Set[Row]) => rows.modifyAll(_.each.when[UserRow]) .using(r => if (r.id == userId) r.modify(_.role).setTo(newRole) else r) 

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

 def makeFixture[STATE, FX, ROW, F[_]]( state: STATE, applyOverrides: F[ROW] => F[ROW] = x => x ): FX = (extractKeys andThen deduplicateKeys andThen enrichWithSampleData andThen applyOverrides andThen logged andThen buildFixture) (state) 

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

हमारा परीक्षण सूट अब इस तरह दिखेगा:

 val dataTable: Seq[DataRow] = Table( ("Package ID", "Customer's role", "Item prices", "Bonus value", "Expected final price") , (1, "customer", Vector(40, 20, 30) , Vector.empty , 90.0) , (2, "customer", Vector(250) , Vector.empty , 225.0) , (3, "customer", Vector(100, 120, 30) , Vector(40) , 210.0) , (4, "customer", Vector(100, 120, 30, 100) , Vector(20, 20) , 279.0) , (5, "vip" , Vector(100, 120, 30, 100, 50), Vector(10, 20, 10), 252.0) ) "   -" - { "'customer'" - { "   " - { "< 250    -  " - { "(:  )" in calculatePriceFor(dataTable, 1) "(:  )" in calculatePriceFor(dataTable, 3) } ">= 250   " - { "   -  10%  " in calculatePriceFor(dataTable, 2) "   -  10%     " in calculatePriceFor(dataTable, 4) } } } "'vip' -    20%      ,       " in calculatePriceFor(dataTable, 5) } 

एक सहायक कोड:

 //    def calculatePriceFor(table: Seq[DataRow], idx: Int) = testInDb( state = makeState(table.row(idx)), execute = runProductionCode(table.row(idx)._1), check = checkResult(table.row(idx)._5) ) def makeState(row: DataRow): Logger => DbFixture = { val items: Map[Int, Int] = ((1 to row._3.length) zip row._3).toMap val bonuses: Map[Int, Int] = ((1 to row._4.length) zip row._4).toMap MyFixtures.makeFixture( state = PackageRelationships .minimal(id = row._1, userId = 1) .withItems(items.keys) .withBonuses(bonuses.keys), overrides = changeRole(userId = 1, newRole = row._2) andThen items.map { case (id, newPrice) => changePrice(id, newPrice) }.foldPls andThen bonuses.map { case (id, newBonus) => changeBonus(id, newBonus) }.foldPls ) } def runProductionCode(id: Int): Database => Double = (db: Database) => new SomeProductionLogic(db).calculatePrice(id) def checkResult(expected: Double): Double => Future[Assertion] = (result: Double) => result shouldBe expected 

टेबल पर नए परीक्षण मामलों को जोड़ना एक तुच्छ कार्य बन जाता है, जो आपको बॉयलरप्लेट के बजाय अधिकतम सीमा की स्थितियों को कवर करने पर ध्यान केंद्रित करने की अनुमति देता है।

अन्य प्रोजेक्ट्स पर पुन: निर्धारण तैयारी कोड

खैर, हमने एक विशिष्ट परियोजना में जुड़नार तैयार करने के लिए बहुत सारे कोड लिखे, इस पर बहुत समय बिताया। यदि हमारे पास कई परियोजनाएं हैं तो क्या होगा? क्या हम हर बार पहिया और कॉपी-पेस्ट को रोकने के लिए बर्बाद होते हैं?

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

किसी वस्तु को गिरवी रखने के लिए, हमें यह जानने की जरूरत नहीं है कि यह वस्तु अंदर क्या है, इसके पास क्या क्षेत्र और विधियां हैं। यह केवल हमारे लिए महत्वपूर्ण है कि एक निश्चित हस्ताक्षर वाले log व्यवहार को इसके लिए परिभाषित किया जाए। प्रत्येक कक्षा में एक निश्चित Logged इन इंटरफ़ेस को लागू करना Logged होगा, और यह हमेशा संभव नहीं है - उदाहरण के लिए, पुस्तकालय या मानक कक्षाओं में। टाइपकास्टेस के मामले में, सब कुछ बहुत सरल है। हम लॉग Logged का एक उदाहरण बना सकते हैं, उदाहरण के लिए, जुड़नार के लिए, और इसे पठनीय रूप में प्रदर्शित करते हैं। और अन्य सभी प्रकारों के लिए, Any प्रकार के लिए एक उदाहरण बनाएं और किसी भी ऑब्जेक्ट को मुफ्त में उनके आंतरिक प्रतिनिधित्व में लॉग करने के लिए मानक toString विधि का उपयोग करें।

 trait Logged[A] { def log(a: A)(implicit logger: Logger): A } //   Future implicit def futureLogged[T]: Logged[Future[T]] = new Logged[Future[T]] { override def log(futureT: Future[T])(implicit logger: Logger): Future[T] = { futureT.map { t => // map  Future       ,   //  logger.info(t.toString()) t } } } // ,        implicit def anyNoLogged[T]: Logged[T] = new Logged[T] { override def log(t: T)(implicit logger: Logger): T = { logger.info(t.toString()) t } } 

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

 //    def makeFixture[STATE, FX, ROW, F[_]]( state: STATE, applyOverrides: F[ROW] => F[ROW] = x => x ): FX = (extractKeys andThen deduplicateKeys andThen enrichWithSampleData andThen applyOverrides andThen logged andThen buildFixture) (state) override def extractKeys(implicit toKeys: ToKeys[DbState]): DbState => Set[Key] = (db: DbState) => db.toKeys() override def enrichWithSampleData(implicit enrich: Enrich[Key]): Key => Set[Row] = (key: Key) => key.enrich() override def buildFixture(implicit insert: Insertable[Set[Row]]): Set[Row] => DbFixture = (rows: Set[Row]) => rows.insert() // ,   - (, )   trait ToKeys[A] { def toKeys(a: A): Set[Key] // Something => Set[Key] } // ...    trait Enrich[A] { def enrich(a: A): Set[Row] // Set[Key] => Set[Row] } // ...     trait Insertable[A] { def insert(a: A): DbFixture // Set[Row] => DbFixture } //      (.     ) implicit val toKeys: ToKeys[DbState] = ??? implicit val enrich: Enrich[Key] = ??? implicit val insert: Insertable[Set[Row]] = ??? 

स्थिरता जनरेटर को डिजाइन करते समय, मैंने प्रोग्रामिंग और एसओएलआईडी डिजाइन के सिद्धांतों के कार्यान्वयन पर ध्यान केंद्रित किया और इसकी स्थिरता और विभिन्न प्रणालियों के लिए अनुकूलनशीलता के एक संकेतक के रूप में:

• सिंगल रिस्पांसिबिलिटी प्रिंसिपल : प्रत्येक टाइपकास्ट टाइप व्यवहार के एक पहलू का वर्णन करता है।
• ओपन क्लोज्ड सिद्धांत : हम परीक्षणों के लिए मौजूदा लड़ाकू प्रकार को संशोधित नहीं करते हैं, हम इसका विस्तार टिक्सेस के उदाहरणों के साथ करते हैं।
• Liskov प्रतिस्थापन सिद्धांत इस मामले में कोई फर्क नहीं पड़ता, क्योंकि हम विरासत का उपयोग नहीं करते हैं।
• इंटरफ़ेस अलगाव सिद्धांत : हम एक एकल वैश्विक के बजाय कई विशेष टाइमक्लस का उपयोग करते हैं।
• निर्भरता उलटा सिद्धांत : स्थिरता जनरेटर का कार्यान्वयन विशिष्ट मुकाबला प्रकारों पर निर्भर नहीं करता है, लेकिन अमूर्त timeclasses पर।

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

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

परिणाम

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

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

, , , . , , , -. , . !

: Github