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

सेवा के बारे में, डेटा का परीक्षण करें और यह इतना सरल क्यों नहीं है

शुरू करने के लिए, हमारी सेवा के बारे में थोड़ा संदर्भ, ताकि आप समझ सकें कि हमने कुछ निर्णय क्यों लिए।

हम नौकरी चाहने वालों और नियोक्ताओं को एक दूसरे को खोजने में मदद करते हैं:

• नियोक्ता अपनी कंपनियों को पंजीकृत करते हैं और रिक्तियों को पोस्ट करते हैं
• नौकरी चाहने वालों को नौकरियों के लिए खोज, उन्हें पसंदीदा में जोड़ें, खोज परिणामों की सदस्यता लें, फिर से शुरू करें और प्रतिक्रिया भेजें

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

1. परीक्षणों के दौरान हम डेटा बदलते हैं;
2. परीक्षण समानांतर में चलते हैं।

पर्यावरण और जुड़नार का परीक्षण करें

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

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

interface TestFixtureUserApi { @POST("fx/employer/create") fun createEmployerUser(@Body employer: TestEmployer): Call<TestEmployer> } 

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

डीएसएल

तो हम जूही के पास पहुँच गए। परीक्षण के लिए डेटा कैसे सेट किया जाता है?

 initialisation{ applicant { resume { title = "Resume for similar Vacancy" isOptional = true resumeStatus = ResumeStatus.APPROVED } resume { title = "Some other Resume" } } employer { vacancy { title = "Resume for similar Vacancy" } vacancy { title = "Resume for similar Vacancy" description = "Working hard" } vacancy { title = "Resume for similar Vacancy" description = "Working very hard" } } } 

प्रारंभिककरण ब्लॉक में, हम परीक्षण के लिए आवश्यक इकाइयां शुरू करते हैं: ऊपर के उदाहरण में, हमने दो रिज्यूमे के साथ एक आवेदक बनाया, साथ ही एक नियोक्ता जिसने कई रिक्तियों को प्रदान किया।

परीक्षण डेटा के चौराहे से जुड़ी त्रुटियों को खत्म करने के लिए, हम परीक्षण के लिए और प्रत्येक इकाई के लिए एक विशिष्ट पहचानकर्ता उत्पन्न करते हैं।

संस्थाओं के बीच संबंध

डीएसएल के साथ काम करते समय मुख्य सीमा क्या है? इसकी पेड़ की संरचना के कारण, किसी पेड़ की विभिन्न शाखाओं के बीच संबंध बनाना मुश्किल है।

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

 initialisation { applicant { resume { title = "TEST_VACANCY_$uniqueTestId" } } employer { vacancy { title = "TEST_VACANCY_$uniqueTestId" } } } 

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

एक ही प्रकार का प्रारंभिक डेटा

लेकिन क्या होगा अगर आपको बहुत सारी रिक्तियां बनाने की आवश्यकता है? क्या यह हर ब्लॉक इतनी कॉपी है? बिल्कुल नहीं! हम रिक्तियों के एक ब्लॉक के साथ एक विधि बनाते हैं, जो विशिष्ट पहचानकर्ता के आधार पर रिक्तियों की आवश्यक संख्या और उन्हें अलग करने के लिए एक ट्रांसफार्मर को इंगित करता है।

 initialisation { employer { vacancyBlock { size = 10 transformer = { it.also { vacancyDsl -> vacancyDsl.description = "Some description with text ${vacancyDsl.uniqueVacancyId}" } } } } } 

रिक्ति ब्लॉक में, हम संकेत देते हैं कि हमें रिक्तियों के कितने क्लोन बनाने हैं और सीरियल नंबर के आधार पर उन्हें कैसे बदलना है।

परीक्षण में डेटा के साथ काम करें

परीक्षण के दौरान, डेटा के साथ काम करना बहुत सरल हो जाता है। हमारे द्वारा बनाया गया सभी डेटा हमारे पास उपलब्ध है। हमारे कार्यान्वयन में, उन्हें संग्रह के लिए विशेष आवरणों में संग्रहीत किया जाता है। नौकरी के आदेश संख्या (रिक्तियां [0]), दोनों से डेटा प्राप्त किया जा सकता है, इसलिए dsl (रिक्तियों ["मेरी रिक्ति") में सेट किए जा सकने वाले टैग द्वारा, और शॉर्टकट्स (रिक्तियों) से ()

 class TaggedItemContainer<T>( private val items: MutableList<TaggedItem<T>> ) { operator fun get(index: Int): T { return items[index].data } operator fun get(tag: String): T { return items.first { it.tag == tag }.data } operator fun plusAssign(item: TaggedItem<T>) { items += item } fun forEach(action: (T) -> Unit) { for (item in items) action.invoke(item.data) } fun first(): T { return items[0].data } fun second(): T { return items[1].data } fun third(): T { return items[2].data } fun last(): T { return items[items.size - 1].data } } 

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

 initialisation { applicant { resume { title = "TEST_VACANCY_$uniqueTestId" } } }.run { mainScreen { positionField { click() } jobPositionScreen { positionEntry(vacancies.first().title) } searchButton { click() } } } 

डीएसएल में क्या फिट नहीं है

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

डीएसएल कार्यान्वयन

जैसा कि आपने लेख से समझा, परीक्षण डेटा को निर्दिष्ट करने और परीक्षण करने के लिए एल्गोरिथ्म निम्नानुसार है:

• डीएसएल का हिस्सा आरंभीकरण में पार्स किया गया है;
• प्राप्त मूल्यों के आधार पर, सर्वर पर परीक्षण डेटा बनाया जाता है;
• वैकल्पिक परिवर्तन ब्लॉक निष्पादित किया जाता है, जिसमें आप प्रतिक्रियाएं सेट कर सकते हैं;
• एक परीक्षण पहले से ही अंतिम डेटासेट के साथ किया जाता है।

एक इनिशियलाइज़ेशन ब्लॉक से डेटा पार्स करना

वहां कैसा जादू चल रहा है? गौर करें कि शीर्ष-स्तर TestCaseDsl तत्व का निर्माण कैसे किया जाता है:

 @TestCaseDslMarker class TestCaseDsl { val applicants = mutableListOf<ApplicantDsl>() val employers = mutableListOf<EmployerDsl>() val uniqueTestId = CommonUtils.unique fun applicant(block: ApplicantDsl.() -> Unit = {}) { val applicantDsl = ApplicantDsl( uniqueTestId, uniqueApplicantId = CommonUtils.unique applicantDsl.block() applicants += applicantDsl } fun employer(block: EmployerDsl.() -> Unit = {}) { val employerDsl = EmployerDsl( uniqueTestId = uniqueTestId, uniqueEmployerId = CommonUtils.unique employerDsl.block() employers += employerDsl } } 

आवेदक विधि में, हम applicantDsl बनाते हैं।

 @TestCaseDslMarker class ApplicantDsl( val uniqueTestId: String, val uniqueApplicantId: String, var tag: String? = null, var login: String? = null, var password: String? = null, var firstName: String? = null, var middleName: String? = null, var lastName: String? = null, var email: String? = null, var siteId: Int? = null, var areaId: Int? = null, var resumeViewLimit: Int? = null, var isMailingSubscription: Boolean? = null ) { val resumes = mutableListOf<ResumeDsl>() fun resume(block: ResumeDsl.() -> Unit = {}) { val resumeDslBuilder = ResumeDsl( uniqueTestId = uniqueTestId, uniqueApplicantId = uniqueApplicantId, uniqueResumeId = CommonUtils.unique ) resumeDslBuilder.apply(block) this.resumes += resumeDslBuilder } } 

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

कृपया ध्यान दें कि ब्लॉक के निष्पादन के समय यूनिकटेस्टी और यूनीकऐप्लीकेंटआईडी (आपस में संस्थाओं को जोड़ने के लिए विशिष्ट पहचानकर्ता) पहले से ही सेट हैं और हम उन्हें एक्सेस कर सकते हैं।

आंतरिक रूप से प्रारंभिक ब्लॉक में एक समान संरचना होती है:

 fun initialisation(block: TestCaseDsl.() -> Unit): Initialisation { val testCaseDsl = TestCaseDsl().apply(block) val testCase = TestCaseCreator.create(testCaseDsl) return Initialisation(testCase) } 

हम एक परीक्षण बनाते हैं, उस पर ब्लॉक एक्शन लागू करते हैं, फिर सर्वर पर डेटा बनाने और संग्रह में डालने के लिए TestCaseCreator का उपयोग करते हैं। TestCaseCreator.create () फ़ंक्शन काफी सरल है - हम डेटा पर पुनरावृति करते हैं और इसे सर्वर पर बनाते हैं।

नुकसान और विचार

कुछ परीक्षण बहुत समान हैं और केवल इनपुट डेटा और उनके डिस्प्ले को नियंत्रित करने के तरीकों में भिन्न होते हैं (उदाहरण के लिए, जब रिक्ति में विभिन्न मुद्राओं का संकेत दिया जाता है)।

हमारे मामले में, ऐसे कुछ परीक्षण थे, और हमने विशेष सिंटैक्स के साथ डीएसएल को अव्यवस्थित नहीं करने का फैसला किया

DSL से पहले के दिनों में, हमने लंबे समय तक डेटा को अनुक्रमित किया, और समय बचाने के लिए हमने एक कक्षा में बहुत सारे परीक्षण किए और सभी डेटा को एक स्थिर ब्लॉक में बनाया।

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

परिणाम

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

संबंधित सामग्री

यदि आप UI परीक्षण के बारे में हमारे दृष्टिकोण में रुचि रखते हैं, तो शुरू करने से पहले, मेरा सुझाव है कि आप निम्नलिखित सामग्रियों से खुद को परिचित करें:

• टाइप-सेफ बिल्डर्स - वेबसाइट kotlinlang.org पर आधिकारिक दस्तावेज;
• कोटलिन डीएसएल: थ्योरी और प्रैक्टिस - कोटलिन डीएसएल और इसके डिकोडिंग के बारे में jPoint 2018 की उत्कृष्ट रिपोर्ट;
• काकाओ - यूआई परीक्षण को फिर से महान कैसे बनाया जाए - यूआई परीक्षणों के लिए काकाओ ढांचे के बारे में बुनियादी ज्ञान;
• डर को कैसे रोका जाए और काकाओ के साथ यूआई परीक्षण लिखना शुरू करें - एप्सकॉन्फ 2019 के साथ काकाओ पर रिपोर्ट। अभी तक केवल स्लाइड उपलब्ध हैं, फिर एक वीडियो होगा।

आगे क्या है

यह लेख Android में UI परीक्षणों को लिखने और समर्थन करने के लिए उपकरणों और उच्च-स्तरीय रूपरेखाओं के बारे में एक श्रृंखला है। जैसे ही नए हिस्से उपलब्ध होंगे, मैं उन्हें इस लेख से जोड़ दूंगा।