मास्टर एंड्रॉइड टीडीडी:परीक्षण-संचालित विकास के लिए एक व्यावहारिक मार्गदर्शिका

आवश्यकताएँ

• कोटलिन का बुनियादी ज्ञान
• यूनिट परीक्षण लिखने का बुनियादी ज्ञान
• मजाक और दावे का ज्ञान

टेस्ट संचालित विकास कैसे काम करता है

1. एक असफल परीक्षा लिखना (गुलाबी वर्ग)।
2. परीक्षा पास करने के लिए कोड लागू करना (हरा वर्ग)
3. यह सुनिश्चित करते हुए कि परीक्षण लगातार पास होते रहें (हल्का हरा वर्ग)।
आवश्यकतानुसार कोड (नीला वर्ग) को दोबारा तैयार करना।
4. एक नया असफल परीक्षण लिखना (प्रवाह को फिर से शुरू करना)

एक असफल परीक्षा लिखना (पिंक स्क्वायर)

टिप्स

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

@Test fun `a sum is calculated from two input numbers`() {}

• अर्थपूर्ण नामों का उपयोग करें:अपने परीक्षणों को वर्णनात्मक रूप से नाम दें ताकि उन्हें पढ़ने वाला कोई भी व्यक्ति जान सके कि परीक्षण क्या जाँच रहा है।

@Test fun `Font Ratio is fetched from data source INITIALLY`() {}

सामान्य गलतियों से बचना चाहिए

• एक साथ बहुत अधिक परीक्षण करना: एक ही परीक्षण में अनेक चीज़ों का परीक्षण करने से बचें। इससे यह पहचानना कठिन हो सकता है कि क्या विफल हो रहा है।

// Don't do this
@Test fun `pixelSize fits the standart sizes while fontSize is bigger than minumum supported font size but matches the list of special levels of size`() {}

• कार्यान्वयन विवरण पर भरोसा: ऐसे परीक्षण न लिखें जो कोड की आंतरिक कार्यप्रणाली से कसकर जुड़े हों। परीक्षणों को व्यवहार पर ध्यान केंद्रित करना चाहिए, न कि कार्यान्वयन पर।

// Don't do this
@Test fun `pixelSize is Long and Non-Null and fits the standart sizes then calculated font size is non-null and of type Dimention`() {}

परीक्षा पास करने के लिए कोड लागू करना (ग्रीन स्क्वायर)

टिप्स

• न्यूनतम कोड लिखें:सबसे सरल कोड लिखें जो असफल परीक्षा को उत्तीर्ण कर दे। आप यहां अति-इंजीनियरिंग से बचने के तरीके के बारे में अधिक पढ़ सकते हैं।

// Test Case 
@Test fun `Storage stores font ratio in key-value`() { 
 // Given
 val fontRatio = 2.0f
 val mockEditor = mockk<SharedPreferences.Editor>(relaxed = true)
 every { mockSharedPreference.edit() } returns mockEditor 
 every { mockEditor.putFloat(any(), any()) } returns mockEditor 
 every { mockEditor.apply() } just Runs 
 // When 
 storage.saveFontRatio(fontRatio) 
 // Then
 verify(exactly = 1) { 
 mockEditor.apply() 
 }
}
// Correct Implementation - Avoid extra implementation
class SharedPreferenceHelper( 
 private val sharedPreferences: SharedPreferences 
) { 
 fun saveFontRatio(fontRatio: Float) {
 sharedPreferences.edit().putFloat("font-ratio", fontRatio).apply() 
 } 
}
// Wrong Implementation 
class SharedPreferenceHelper(
 private val sharedPreferences: SharedPreferences
) { 
 fun saveFontRatio(fontRatio: Float) { 
 if (fontRatio <= 0.0f) 
 throw IllegalArgumentException("Font ratio must be greater than 0.0f") 
 storeValue(key = FONT_RATIO_KEY, value = fontRatio) 
} 
 private fun storeValue(key: String, value: Float){
 val editor = sharedPreferences.edit() editor.putFloat(key, value)
 editor.apply() 
 }
 fun getFontRatio(): Float { 
 return sharedPreferences.getFloat("font_ratio", 1.0f) } 
}

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

class ... {
 override fun getDefaultFontSize(): Float {
 val zoomRatio = DEFAULT_SSPEED * DEFAULT_FONT_RATIO / deviceDensity 
 val fontSize = zoomRatio * standardFontSize 
 return fontSize 
 }
 override fun getFontSizeBySSpeed(speed: Int): Float {
 val zoomRatio = speed * DEFAULT_FONT_RATIO / deviceDensity 
 val fontSize = zoomRatio * standardFontSize 
 return fontSize 
 }
}

class ... { 
 override fun getDefaultFontSize(): Float = calculate(DEFAULT_AGE)
 override fun getFontSizeByAge(age: Int): Float = calculate(age) 
 private fun calculate(age: Int): Float {
 val zoomRatio = age * DEFAULT_FONT_RATIO / deviceDensity 
 val fontSize = zoomRatio * standardFontSize 
 return fontSize 
 }
}

सामान्य गलतियाँ जिनसे बचना चाहिए:

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

कोड को दोबारा तैयार करना (नीला वर्ग) और परीक्षण की सफलता सुनिश्चित करना (हल्का हरा वर्ग)

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

टिप्स

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

सामान्य गलतियाँ जिनसे बचना चाहिए:

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

एक नया असफल परीक्षण लिखना (प्रवाह को पुनः आरंभ करना)

टिप्स

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

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

सामान्य गलतियाँ जिनसे बचना चाहिए:

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

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

टीडीडी का उपयोग करके कैसे विकास करें

फ़ॉन्ट आकार ऑटो सेटिंग फ़ीचर डेटा फ़्लो चार्ट

टेस्ट कैसे लिखें

• UserRepositoryTest
• AutoScrollSettingTest
• UserSettingsViewModelTest

• एएए
• दिया/कब/तब

@Test fun `strategy A`(){ 
 // Arrange
 // Act 
 // Assert 
}
@Test fun `strategy B`(){ 
 // Given 
 // When 
 // Then 
}

class UserProfileViewModel is tested for` {
 // Unimplemented Class 
 val viewModel = UserProfileViewModel()
 @Test
 fun Font Ratio is fetched from data source`(){}
 @Test
 fun `Scroll Speed update is called so fontSize calculations are triggered`() {}
 @Test
 fun `Font Ratio is updated with new emissions from data source`() {}
}

class `UserProfileViewModel is tested for` {
 init {
 Dispatchers.setMain(Dispatchers.Unconfined)
 }
 val mockUserRepository = mockk<UserRepository>()
 @Test
 fun `Font Ratio is fetched from data source`() = runTest {
 // Given
 val expectedRatio = 2.0f
 every { mockUserRepository.fontRatio } returns flowOf(FontRatioUiModel(expectedRatio))
 val viewModel = UserProfileViewModel(userRepository = mockUserRepository)
 // When
 viewModel.fontRatio.test {
 val fromDataSource = expectItem()
 // Then
 assertEquals(/* expected = */ expectedRatio, /* actual = */ fromDataSource.fontRatio)
 }
 }
...
}

class UserProfileViewModel(
 userRepository: UserRepository
) : ViewModel() {
 val fontRatio: StateFlow<FontRatioUiModel> = userRepository.fontRatio.stateIn(
 initialValue = FontRatioUiModel(DEFAULT_FONT_RATIO),
 scope = viewModelScope,
 started = SharingStarted.Lazily
 )
 companion object {
 private const val DEFAULT_FONT_RATIO = 1.0f
 }
}

स्रोत कोड

निष्कर्ष

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