मैं कोटलिन में इकाई परीक्षण संसाधनों का प्रबंधन कैसे करता हूं, जैसे कि डेटाबेस कनेक्शन या एक एम्बेडेड इलास्टिक्स खोज सर्वर को शुरू करना / रोकना?

Question 1

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

मैंने @Beforeअपने परीक्षण वर्ग में एक विधि पर JUnit एनोटेशन का उपयोग करने की कोशिश की और यह ठीक काम करता है, लेकिन यह सही व्यवहार नहीं है क्योंकि यह केवल एक बार के बजाय प्रत्येक परीक्षण मामले को चलाता है।

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

तो मैं अपने सभी परीक्षण मामलों के लिए सिर्फ एक बार इस एम्बेडेड डेटाबेस को कैसे बनाऊं?

class MyTest {
    @Before fun setup() {
       // works in that it opens the database connection, but is wrong 
       // since this is per test case instead of being shared for all
    }

    @BeforeClass fun setupClass() {
       // what I want to do instead, but results in error because 
       // this isn't a static method, and static keyword doesn't exist
    }

    var referenceToServer: ServerType // wrong because is not static either

    ...
}

नोट: यह प्रश्न जानबूझकर लिखा गया है और इसका उत्तर लेखक ( स्व-उत्तर वाले प्रश्न ) द्वारा दिया गया है , ताकि सामान्यतः पूछे जाने वाले कोटलिन विषयों के उत्तर एसओ में मौजूद हों।

Question 2

आपके यूनिट परीक्षण वर्ग को आमतौर पर परीक्षण विधियों के एक समूह के लिए साझा संसाधन का प्रबंधन करने के लिए कुछ चीजों की आवश्यकता होती है। और कोटलिन में आप उपयोग कर सकते हैं @BeforeClassऔर @AfterClassटेस्ट क्लास में नहीं, बल्कि एनोटेशन के साथ इसके साथी ऑब्जेक्ट के भीतर ।@JvmStatic

एक परीक्षण वर्ग की संरचना इस तरह दिखाई देगी:

class MyTestClass {
    companion object {
        init {
           // things that may need to be setup before companion class member variables are instantiated
        }

        // variables you initialize for the class just once:
        val someClassVar = initializer() 

        // variables you initialize for the class later in the @BeforeClass method:
        lateinit var someClassLateVar: SomeResource 

        @BeforeClass @JvmStatic fun setup() {
           // things to execute once and keep around for the class
        }

        @AfterClass @JvmStatic fun teardown() {
           // clean up after this class, leave nothing dirty behind
        }
    }

    // variables you initialize per instance of the test class:
    val someInstanceVar = initializer() 

    // variables you initialize per test case later in your @Before methods:
    var lateinit someInstanceLateZVar: MyType 

    @Before fun prepareTest() { 
        // things to do before each test
    }

    @After fun cleanupTest() {
        // things to do after each test
    }

    @Test fun testSomething() {
        // an actual test case
    }

    @Test fun testSomethingElse() {
        // another test case
    }

    // ...more test cases
}

उपरोक्त को देखते हुए, आपको इसके बारे में पढ़ना चाहिए:

साथी वस्तुएं - जावा में क्लास ऑब्जेक्ट के समान, लेकिन प्रति क्लास एक सिंगलटन जो स्थिर नहीं है
@JvmStatic - एक एनोटेशन जो जावा इंटरोप के लिए बाहरी वर्ग पर एक स्थैतिक विधि में एक साथी ऑब्जेक्ट विधि को बदल देता है
lateinit- varजब आप एक अच्छी तरह से परिभाषित जीवनचक्र रखते हैं, तो एक संपत्ति को बाद में आरंभ करने की अनुमति देता है
Delegates.notNull()- lateinitएक संपत्ति के बदले इस्तेमाल किया जा सकता है जिसे पढ़ने से पहले कम से कम एक बार सेट किया जाना चाहिए।

कोटलिन के लिए परीक्षण कक्षाओं के पूर्ण उदाहरण हैं जो एम्बेडेड संसाधनों का प्रबंधन करते हैं।

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

class TestServerWithPlugin {
    companion object {
        val workingDir = Paths.get("test-data/solr-standalone").toAbsolutePath()
        val coreWithPluginDir = workingDir.resolve("plugin-test/collection1")

        lateinit var server: Server

        @BeforeClass @JvmStatic fun setup() {
            assertTrue(coreWithPluginDir.exists(), "test core w/plugin does not exist $coreWithPluginDir")

            // make sure no system properties are set that could interfere with test
            resetEnvProxy()
            cleanSysProps()
            routeJbossLoggingToSlf4j()
            cleanFiles()

            val config = mapOf(...) 
            val configLoader = ServerConfigFromOverridesAndReference(workingDir, config) verifiedBy { loader ->
                ...
            }

            assertNotNull(System.getProperty("solr.solr.home"))

            server = Server(configLoader)
            val (serverStarted, message) = server.run()
            if (!serverStarted) {
                fail("Server not started: '$message'")
            }
        }

        @AfterClass @JvmStatic fun teardown() {
            server.shutdown()
            cleanFiles()
            resetEnvProxy()
            cleanSysProps()
        }

        private fun cleanSysProps() { ... }

        private fun cleanFiles() {
            // don't leave any test files behind
            coreWithPluginDir.resolve("data").deleteRecursively()
            Files.deleteIfExists(coreWithPluginDir.resolve("core.properties"))
            Files.deleteIfExists(coreWithPluginDir.resolve("core.properties.unloaded"))
        }
    }

    val adminClient: SolrClient = HttpSolrClient("http://localhost:8983/solr/")

    @Before fun prepareTest() {
        // anything before each test?
    }

    @After fun cleanupTest() {
        // make sure test cores do not bleed over between test cases
        unloadCoreIfExists("tempCollection1")
        unloadCoreIfExists("tempCollection2")
        unloadCoreIfExists("tempCollection3")
    }

    private fun unloadCoreIfExists(name: String) { ... }

    @Test
    fun testServerLoadsPlugin() {
        println("Loading core 'withplugin' from dir ${coreWithPluginDir.toString()}")
        val response = CoreAdminRequest.createCore("tempCollection1", coreWithPluginDir.toString(), adminClient)
        assertEquals(0, response.status)
    }

    // ... other test cases
}

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

class TestAccountManager {
    companion object {
        init {
            // we need to control the "java.library.path" or sqlite cannot find its libraries
            val dynLibPath = File("./src/test/dynlib/").absoluteFile
            System.setProperty("java.library.path", dynLibPath.toString());

            // TEST HACK: if we kill this value in the System classloader, it will be
            // recreated on next access allowing java.library.path to be reset
            val fieldSysPath = ClassLoader::class.java.getDeclaredField("sys_paths")
            fieldSysPath.setAccessible(true)
            fieldSysPath.set(null, null)

            // ensure logging always goes through Slf4j
            System.setProperty("org.eclipse.jetty.util.log.class", "org.eclipse.jetty.util.log.Slf4jLog")
        }

        private val localDbPort = 19444

        private lateinit var localDb: DynamoDBProxyServer
        private lateinit var dbClient: AmazonDynamoDBClient
        private lateinit var dynamo: DynamoDB

        @BeforeClass @JvmStatic fun setup() {
            // do not use ServerRunner, it is evil and doesn't set the port correctly, also
            // it resets logging to be off.
            localDb = DynamoDBProxyServer(localDbPort, LocalDynamoDBServerHandler(
                    LocalDynamoDBRequestHandler(0, true, null, true, true), null)
            )
            localDb.start()

            // fake credentials are required even though ignored
            val auth = BasicAWSCredentials("fakeKey", "fakeSecret")
            dbClient = AmazonDynamoDBClient(auth) initializedWith {
                signerRegionOverride = "us-east-1"
                setEndpoint("http://localhost:$localDbPort")
            }
            dynamo = DynamoDB(dbClient)

            // create the tables once
            AccountManagerSchema.createTables(dbClient)

            // for debugging reference
            dynamo.listTables().forEach { table ->
                println(table.tableName)
            }
        }

        @AfterClass @JvmStatic fun teardown() {
            dbClient.shutdown()
            localDb.stop()
        }
    }

    val jsonMapper = jacksonObjectMapper()
    val dynamoMapper: DynamoDBMapper = DynamoDBMapper(dbClient)

    @Before fun prepareTest() {
        // insert commonly used test data
        setupStaticBillingData(dbClient)
    }

    @After fun cleanupTest() {
        // delete anything that shouldn't survive any test case
        deleteAllInTable<Account>()
        deleteAllInTable<Organization>()
        deleteAllInTable<Billing>()
    }

    private inline fun <reified T: Any> deleteAllInTable() { ... }

    @Test fun testAccountJsonRoundTrip() {
        val acct = Account("123",  ...)
        dynamoMapper.save(acct)

        val item = dynamo.getTable("Accounts").getItem("id", "123")
        val acctReadJson = jsonMapper.readValue<Account>(item.toJSON())
        assertEquals(acct, acctReadJson)
    }

    // ...more test cases

}

नोट: उदाहरणों के कुछ भागों के साथ संक्षिप्त किया गया है...

Question 3

परीक्षण में कॉलबैक से पहले / बाद में संसाधनों का प्रबंधन करना, जाहिर है, इसके पक्ष में है:

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

इसकी कुछ सहमती भी है। उनमें से एक महत्वपूर्ण यह है कि यह कोड को प्रदूषित करता है और कोड को एकल जिम्मेदारी सिद्धांत का उल्लंघन करता है। टेस्ट अब न केवल कुछ परीक्षण करते हैं, बल्कि एक हेवीवेट आरंभीकरण और संसाधन प्रबंधन करते हैं। यह कुछ मामलों में ठीक हो सकता है (जैसे कि कॉन्फ़िगर करनाObjectMapper ), लेकिन java.library.pathकिसी अन्य प्रक्रिया को संशोधित करना या उसमें बदलाव करना (या अंतर्निहित डेटाबेस) इतनी मासूम नहीं है।

क्यों नहीं उन सेवाओं को "इंजेक्शन" के लिए आपके परीक्षण के लिए निर्भरता के रूप में माना जाता है, जैसे कि 12factor.net द्वारा वर्णित है ।

इस तरह आप परीक्षण कोड के बाहर कहीं और निर्भरता सेवाओं को शुरू और शुरू करते हैं।

आजकल वर्चुअलाइजेशन और कंटेनर लगभग हर जगह हैं और अधिकांश डेवलपर्स की मशीनें डॉकर को चलाने में सक्षम हैं। : और आवेदन के सबसे एक dockerized संस्करण है Elasticsearch , DynamoDB , PostgreSQL और इतने पर। डॉकर बाहरी सेवाओं के लिए एक सही समाधान है जो आपके परीक्षणों की आवश्यकता है।

यह एक स्क्रिप्ट हो सकती है जो हर बार एक डेवलपर द्वारा मैन्युअल रूप से चलाया जाता है, जब वह परीक्षणों को निष्पादित करना चाहता है।
यह बिल्ड टूल द्वारा चलाया जाने वाला कार्य हो सकता है (उदाहरण के लिए ग्रेडल में कमाल की dependsOnऔर finalizedByडीएसएल निर्भरता को परिभाषित करने के लिए है)। एक कार्य, निश्चित रूप से उसी स्क्रिप्ट को निष्पादित कर सकता है जिसे डेवलपर मैन्युअल रूप से शेल-आउट / प्रक्रिया निष्पादित करके उपयोग करता है।
यह परीक्षण निष्पादन से पहले आईडीई द्वारा संचालित एक कार्य हो सकता है । फिर से, यह उसी स्क्रिप्ट का उपयोग कर सकता है।
अधिकांश CI / CD प्रदाताओं के पास "सेवा" की धारणा है - एक बाहरी निर्भरता (प्रक्रिया) जो आपके निर्माण के समानांतर चलती है और इसे सामान्य एसडीके / कनेक्टर / एपीआई के माध्यम से एक्सेस किया जा सकता है: गिटलैब , ट्रैविस , बिटबकेट , अप्पेयर , सेमाफोर , ...

यह दृष्टिकोण:

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

बेशक, इसकी खामियां हैं (मूल रूप से, मेरे द्वारा शुरू किए गए बयान):

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