टेस्ट्स ऑफ़ थेकिंग से बचना: एक नियत से एक जोर तक एक शॉर्टकट का निर्माण

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

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

समस्या

यदि आपको कभी भी परीक्षणों से जूझना पड़ता है (जो मायने नहीं रखता है: यूनिट-टेस्ट, इंटीग्रेशनल या फंक्शनल), तो वे क्रमिक निर्देशों के एक सेट के रूप में लिखे जाते हैं। उदाहरण के लिए:

// The following tests describe a simple internet store. // Depending on their role, bonus amount and the order's // subtotal, users may receive a discount of some size. "If user's role is 'customer'" - { import TestHelper._ "And if subtotal < 250 after bonuses - no discount" 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 } "And if subtotal >= 250 after bonuses - 10% off" 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 } } "If user's role is 'vip'" - {/*...*/} 

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

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

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

इस दर्द के सभी, मेरी राय में, इस तरह के परीक्षण डिजाइन की दो गहरी समस्याओं का एक लक्षण है:

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 ) और अपेक्षित परिणाम ( check ) की जांच का उपयोग करके। इस रचना के लिए इनपुट बहुत पहला कदम होगा - स्थिरता। चलो परिणामी उच्च-क्रम फ़ंक्शन को परीक्षण जीवनचक्र फ़ंक्शन कहते हैं ।

 def runTestCycle[FX, DEP, OUT, F[_]]( fixture: FX, prepare: FX => DEP, execute: DEP => OUT, check: OUT => F[Assertion] ): F[Assertion] = // In Scala instead of writing check(execute(prepare(fixture))) // one can use a more readable version using the andThen function: (prepare andThen execute andThen check) (fixture) 

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

 // Sets up the fixture — implemented separately 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) => { // By passing an instance of the Logged typeclass for T as an argument, // we get an ability to “add” behavior log() to the abstract “that” member. // More on typeclasses later on. loggedT.log(that) // We could even do: that.log() that // The object gets returned unaltered } def runTestCycle[FX, DEP, OUT, F[_]]( fixture: FX, prepare: FX => DEP, execute: DEP => OUT, check: OUT => F[Assertion] )(implicit loggedOut: Logged[OUT]): F[Assertion] = // Insert logged right after receiving the result - after execute() (prepare andThen execute andThen logged andThen check) (fixture) 

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

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

 val fixture: SomeMagicalFixture = ??? // Comes from somewhere else 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 // The creation and filling of Database is hidden in testInDb "If user's role is '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) 

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

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

 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) 

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

 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) ) "If the buyer's role is" - { "a customer" - { "And the total price of items" - { "< 250 after applying bonuses - no discount" - { "(case: no bonuses)" in calculatePriceFor(dataTable, 1) "(case: has bonuses)" in calculatePriceFor(dataTable, 3) } ">= 250 after applying bonuses" - { "If there are no bonuses - 10% off on the subtotal" in calculatePriceFor(dataTable, 2) "If there are bonuses - 10% off on the subtotal after applying bonuses" in calculatePriceFor(dataTable, 4) } } } "a vip - then they get a 20% off before applying bonuses and then all the other rules apply" in calculatePriceFor(dataTable, 5) } 

और सहायक कोड:

 // Reusable test's body 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 प्रकार के लिए एक उदाहरण जो Any मानक विधि का उपयोग करता है toString() फ्री में उनके आंतरिक प्रतिनिधित्व में प्रत्येक ऑब्जेक्ट को लॉग इन करने के लिए।

 trait Logged[A] { def log(a: A)(implicit logger: Logger): A } // For all Futures 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 on a Future lets us modify its result after it finishes logger.info(t.toString()) t } } } // Fallback in case there are no suitable implicits in scope implicit def anyNoLogged[T]: Logged[T] = new Logged[T] { override def log(t: T)(implicit logger: Logger): T = { logger.info(t.toString()) t } } 

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

 // Fixture preparation function 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() // Behavior of splitting something (eg a dataset) into keys trait ToKeys[A] { def toKeys(a: A): Set[Key] // Something => Set[Key] } // ...converting keys into rows trait Enrich[A] { def enrich(a: A): Set[Row] // Set[Key] => Set[Row] } // ...and inserting rows into the database trait Insertable[A] { def insert(a: A): DbFixture // Set[Row] => DbFixture } // To be implemented in our project (see the example at the end of the article) implicit val toKeys: ToKeys[DbState] = ??? implicit val enrich: Enrich[Key] = ??? implicit val insert: Insertable[Set[Row]] = ??? 

इस स्थिरता तैयारी उपकरण को डिज़ाइन करते समय, मैंने यह सुनिश्चित करने के लिए एक ठोस के रूप में SOLID सिद्धांतों का उपयोग किया कि यह बनाए रखने योग्य और विस्तार योग्य है:

• सिंगल रिस्पांसिबिलिटी सिद्धांत : प्रत्येक टाइपकास्ट एक प्रकार के एक और केवल एक व्यवहार का वर्णन करता है।
• खुले / बंद सिद्धांत : हम उत्पादन वर्गों में से किसी को भी संशोधित नहीं करते हैं; इसके बजाय, हम उन्हें टाइपकास्ट के उदाहरणों के साथ बढ़ाते हैं।
• Liskov प्रतिस्थापन सिद्धांत यहाँ लागू नहीं होता है क्योंकि हम विरासत का उपयोग नहीं करते हैं।
• इंटरफ़ेस पृथक्करण सिद्धांत : हम एक वैश्विक एक के विपरीत कई विशिष्ट टाइपकालेज़ का उपयोग करते हैं।
• निर्भरता उलटा सिद्धांत : स्थिरता तैयार करने का कार्य ठोस प्रकारों पर निर्भर नहीं करता है, बल्कि अमूर्त टाइपकास्टेस पर निर्भर करता है।

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

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

निचला रेखा

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

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

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

समाधान के लिए लिंक और एक पूरा उदाहरण यहां पाया जा सकता है: जीथब । अपने परीक्षण के साथ मज़े करो!