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

परीक्षण के स्तर: Unit, Integration, E2E

यूनिट परीक्षण

यूनिट परीक्षण मोबाइल ऐप परीक्षण की नींव हैं। वे कोड की सबसे छोटी इकाई — एकल फ़ंक्शन, विधि या क्लास को सिस्टम के बाकी हिस्सों से अलग करके जाँचते हैं। मोबाइल डेवलपमेंट में, यूनिट परीक्षण JUnit (Android) और XCTest (iOS) पर लिखे जाते हैं। एक अच्छा यूनिट परीक्षण तेज़, स्वतंत्र और दोहराने योग्य होना चाहिए — यह नेटवर्क, डेटाबेस या UI घटकों पर निर्भर नहीं होना चाहिए। अलगाव के लिए टेस्ट डबल्स का उपयोग किया जाता है: मॉक, स्टब और फेक।

Mockito (Java/Kotlin) और MockK (Kotlin-first) Android पर मॉक ऑब्जेक्ट बनाने के लिए लोकप्रिय लाइब्रेरी हैं। iOS पर, OCMock, Cuckoo या मैन्युअल प्रोटोकॉल का उपयोग किया जाता है। नियम: यूनिट परीक्षणों को व्यावसायिक तर्क और डेटा मॉडल को कवर करना चाहिए। UI परीक्षणों को यूनिट परीक्षणों की नकल नहीं करनी चाहिए — वे इंटरफ़ेस के साथ उपयोगकर्ता की सहभागिता की जाँच करते हैं।

इंटीग्रेशन परीक्षण

इंटीग्रेशन परीक्षण घटकों के बीच सहभागिता की जाँच करते हैं: डेटाबेस के साथ रिपॉजिटरी, API सेवा के साथ ViewModel, स्क्रीन के बीच नेविगेशन। यूनिट परीक्षणों के विपरीत, इंटीग्रेशन परीक्षण वास्तविक या वास्तविकता के करीब निर्भरताओं का उपयोग करते हैं (जैसे, इन-मेमोरी डेटाबेस या मॉक सर्वर)। Robolectric बिना एम्युलेटर के JVM पर Android परीक्षण चलाने का फ्रेमवर्क है, जो इंटीग्रेशन परीक्षणों को 10 गुना तेज़ करता है।

स्नैपशॉट परीक्षण (गोल्डन टेस्ट) एक विशेष प्रकार के इंटीग्रेशन परीक्षण हैं जो रेंडर किए गए UI घटक की तुलना संदर्भ छवि (स्नैपशॉट) से करते हैं। यदि दिखावट बदलती है, तो परीक्षण विफल हो जाता है — डेवलपर देखता है कि क्या बदला। Facebook SnapshotTestCase (iOS) और Shot (Android) स्नैपशॉट परीक्षण के लिए लोकप्रिय उपकरण हैं।

E2E और UI परीक्षण

E2E परीक्षण (एंड-टू-एंड) शुरू से अंत तक पूर्ण उपयोगकर्ता परिदृश्य की जाँच करते हैं: ऐप लॉन्च, लॉगिन, कार्रवाई करना, परिणाम की जाँच। UI परीक्षण E2E का एक उपसमूह है जो इंटरफ़ेस पर केंद्रित है। उपकरण: Espresso (Android), XCUITest (iOS), Detox (React Native)। E2E परीक्षण सबसे धीमे होते हैं, इसलिए इन्हें CI पर अलग से चलाया जाता है — आमतौर पर रात्रिकालीन बिल्ड पर।

iOS उपकरण: XCTest और XCUITest

XCTest

XCTest मोबाइल ऐप के यूनिट परीक्षण के लिए Apple का अंतर्निहित फ्रेमवर्क है। XCTestRunner सिम्युलेटर या वास्तविक डिवाइस पर परीक्षण चलाता है। परीक्षण XCTestCase से विरासत प्राप्त करते हैं, तैयारी और सफाई के लिए setUp और tearDown शामिल करते हैं। XCTest में जाँच के लिए XCTAssert (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) और एसिंक्रोनस संचालन की प्रतीक्षा के लिए XCTWaiter शामिल है।

सरल XCTest परीक्षण का उदाहरण: User मॉडल बनाना, आरंभीकरण की सत्यता, नाम स्वरूपण और आयु गणना की जाँच। कोड कवरेज Xcode में दिखाता है कि कोड की कौन सी पंक्तियाँ परीक्षणों द्वारा कवर की गई हैं — व्यावसायिक परियोजनाओं का लक्ष्य: व्यावसायिक तर्क का कम से कम 70–80% कवरेज। XCTest xcodebuild test के माध्यम से Xcode Server और CI सिस्टम के साथ एकीकृत है।

XCUITest

XCUITest UI परीक्षण के लिए Apple का फ्रेमवर्क है। यह एक्सेसिबिलिटी पहचानकर्ताओं के माध्यम से काम करता है: XCUIElementQuery बटन, इनपुट फ़ील्ड, टेबल को label, identifier या प्रकार के आधार पर ढूँढता है। XCUITest क्रियाओं का अनुक्रम रिकॉर्ड करता है (रिकॉर्ड/प्लेबैक) और परीक्षण कोड उत्पन्न करता है। महत्वपूर्ण: स्थिर परीक्षण संचालन के लिए सभी UI तत्वों में accessibilityIdentifier होना चाहिए।

Android उपकरण: JUnit, Espresso, Robolectric

JUnit और Mockito

JUnit Java/Kotlin पर मोबाइल ऐप के मॉड्यूलर परीक्षण के लिए मूल फ्रेमवर्क है। Android पर, JUnit 4 (नवीनतम स्थिर संस्करण 4.13.2) और नई परियोजनाओं के लिए JUnit 5 का उपयोग किया जाता है। Mockito मॉक ऑब्जेक्ट बनाने की लाइब्रेरी है: when(mock.method()).thenReturn(value) — परीक्षण की गई क्लास को निर्भरताओं से अलग करने का मानक पैटर्न।

Android के लिए JUnit परीक्षण का उदाहरण:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso और UI Automator

Espresso Android UI परीक्षणों के लिए Google का फ्रेमवर्क है। Espresso स्वचालित रूप से UI थ्रेड के साथ सिंक्रोनाइज़ होता है: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso लिखने में आसान और अंतर्निहित आइडल स्थिति प्रतीक्षा के कारण स्थिर है। UI Automator क्रॉस-एप्लिकेशन परीक्षणों के लिए फ्रेमवर्क है जो सिस्टम तत्वों (अनुमति संवाद, अधिसूचना छाया) के साथ बातचीत कर सकता है।

क्रॉस-प्लेटफ़ॉर्म उपकरण: Detox, Appium

React Native के लिए Detox

Detox Wix द्वारा React Native मोबाइल ऐप के परीक्षण के लिए ग्रे-बॉक्स E2E फ्रेमवर्क है। Detox एक ही परीक्षण कोडबेस से दोनों प्लेटफ़ॉर्म पर काम करता है, अंदरूनी रूप से Espresso (Android) और XCUITest (iOS) का उपयोग करता है। Detox स्वचालित रूप से ऐप के आइडल होने (कोई एनिमेशन, नेटवर्क अनुरोध, टाइमर नहीं) तक प्रतीक्षा करता है और उसके बाद ही अगली कार्रवाई करता है।

Appium

Appium एक सार्वभौमिक क्रॉस-प्लेटफ़ॉर्म फ्रेमवर्क है जो Android, iOS, वेब और हाइब्रिड ऐप का समर्थन करता है। Appium WebDriver प्रोटोकॉल का उपयोग करता है और किसी भी प्रोग्रामिंग भाषा (Java, Python, JS, Ruby) का समर्थन करता है। Appium Server एक HTTP सर्वर के रूप में काम करता है जो कमांड को मूल UI Automator / XCUITest कमांड में अनुवादित करता है। Appium का मुख्य दोष गति है: परीक्षण मूल Espresso या XCUITest की तुलना में धीमे चलते हैं।

TDD और BDD: परीक्षण पद्धतियाँ

TDD: टेस्ट-ड्रिवेन डेवलपमेंट

TDD एक मोबाइल ऐप परीक्षण पद्धति है जहाँ कार्यान्वयन कोड से पहले परीक्षण लिखा जाता है। Red-Green-Refactor चक्र: (1) एक परीक्षण लिखें जो विफल होता है (Red), (2) परीक्षण पास कराने के लिए न्यूनतम कोड लिखें (Green), (3) परीक्षण पास रखते हुए कोड को रीफैक्टर करें। TDD नई कार्यक्षमता के लिए 100% परीक्षण कवरेज और स्वच्छ आर्किटेक्चर देता है, क्योंकि परीक्षण आवश्यकता का पहला विनिर्देश है।

BDD: बिहेवियर-ड्रिवेन डेवलपमेंट

BDD TDD का विस्तार है जहाँ परीक्षण प्राकृतिक भाषा में Given-When-Then प्रारूप में लिखे जाते हैं। Given (संदर्भ) — When (कार्रवाई) — Then (अपेक्षित परिणाम)। BDD परीक्षण टीम के सभी सदस्यों के लिए समझने योग्य हैं: डेवलपर, परीक्षक, विश्लेषक और ग्राहक। Mock vs Stub vs Fake: Mock सहभागिता की जाँच करता है (क्या विधि कॉल की गई), Stub निश्चित डेटा लौटाता है, Fake एक सरलीकृत कार्यशील कार्यान्वयन है (जैसे, इन-मेमोरी DB)। IT Sectr में, हम महत्वपूर्ण व्यावसायिक तर्क के लिए TDD और स्वीकृति परिदृश्यों के लिए BDD का उपयोग करते हैं।

टेस्ट डबल्स उन वस्तुओं का सामान्य नाम है जो परीक्षणों में वास्तविक निर्भरताओं को बदलती हैं। चार प्रकार हैं: Dummy (पैरामीटर भरने के लिए वस्तु, उपयोग नहीं की जाती), Stub (निर्दिष्ट मान लौटाती है), Spy (जाँच के लिए कॉल रिकॉर्ड करती है), Mock (अपेक्षित कॉल को पूर्वनिर्धारित करती है)। अंतर को समझना उचित परीक्षण डिज़ाइन के लिए महत्वपूर्ण है।

CI/CD और Device Farm

CI/CD में परीक्षण स्वचालन

CI/CD — सतत एकीकरण और सतत वितरण: प्रत्येक कोड परिवर्तन पर मोबाइल ऐप को स्वचालित रूप से बनाने और परीक्षण करने की प्रथा। मोबाइल डेवलपमेंट में, CI/CD पाइपलाइन में शामिल हैं: लिंटिंग, यूनिट परीक्षण, इंटीग्रेशन परीक्षण, APK/IPA बिल्ड और UI परीक्षण। GitHub Actions और Bitrise मोबाइल CI/CD के लिए लोकप्रिय प्लेटफ़ॉर्म हैं। परीक्षण तेज़ी से चलने चाहिए: यूनिट परीक्षण 1–2 मिनट में, इंटीग्रेशन 5–10 में, UI परीक्षण 15–30 मिनट में।

Device Farm

Device Farm परीक्षण के लिए वास्तविक उपकरणों का एक फार्म है। Firebase Test Lab (Android) और Xcode Cloud (iOS) सैकड़ों उपकरण मॉडलों तक क्लाउड एक्सेस प्रदान करते हैं। Device Farm उन समस्याओं को उजागर करता है जो एम्युलेटर पर दिखाई नहीं देतीं: विभिन्न स्क्रीन आकार, पुराने उपकरणों पर प्रदर्शन, संगतता समस्याएँ। IT Sectr में, हम नियमित रूप से Android के लिए Firebase Test Lab और iOS के लिए Xcode Cloud का उपयोग करते हैं।