Swift अनुप्रयोगों का E2E परीक्षण: XCUITest से वास्तविक मामलों तक

E2E-परीक्षण iOS-डेवलपर के लिए "गॉड मोड" क्यों है?

कल्पना करें: आपने एकदम सही Swift कोड लिखा, सब कुछ कंपाइल होता है, यूनिट-परीक्षण हरे हैं। आप रिलीज़ जारी करते हैं — और एक घंटे में बग्स आ जाते हैं: iPhone 14 Pro पर "खरीदें" बटन दबता नहीं है, और iPad Mini पर लॉगिन स्क्रीन अमूर्त पेंटिंग जैसी दिखती है। परिचित लगता है? यहीं पर Swift का E2E परीक्षण मंच पर आता है — यह सुनिश्चित करने का एकमात्र तरीका कि आपका ऐप वास्तविक उपयोगकर्ता के हाथों में घड़ी की तरह काम करता है।

End-to-End (E2E) परीक्षण उपयोगकर्ता के पूर्ण परिदृश्य का अनुकरण करते हैं: ऐप लॉन्च करने से लेकर लक्ष्य क्रिया (खरीदारी, पंजीकरण, फॉर्म सबमिट) पूरी करने तक। इस लेख में, हम देखेंगे कि XCUITest Swift को कैसे सेटअप किया जाए ताकि आपके परीक्षण छोटी-मोटी बातों पर विफल न हों, और CI/CD-पाइपलाइन नरक न बने।

आप क्या सीखेंगे:

\n
• XCUITest के साथ स्थिर UI-परीक्षण कैसे लिखें
\n
• Swift के लिए Page Object Model — वास्तविक उदाहरण
\n
• अतुल्यकालिक संचालन और प्रतीक्षाओं को संभालना
\n
• CI/CD में E2E-परीक्षणों का एकीकरण (GitHub Actions + Fastlane)
\n
• शुरुआती लोगों की शीर्ष-3 गलतियाँ और उनसे कैसे बचें
\n

उपकरण: हमें क्या चाहिए

Swift परीक्षण स्वचालन के लिए हम तीन स्तंभों का उपयोग करते हैं:

\n
1. XCUITest — Apple का फ्रेमवर्क, XCTest में निर्मित। यह जेस्चर को अनुकरण करने, UI तत्वों की स्थिति जांचने की अनुमति देता है।
\n
2. Xcode Test Plan — परीक्षण योजनाओं को कॉन्फ़िगर करने के लिए (विभिन्न भाषाएँ, ओरिएंटेशन, डेटा)।
\n
3. Fastlane + GitHub Actions — CI पर परीक्षण चलाने के लिए।
\n

XCUITest का मूल सिंटैक्स सरल है: आप XCUIApplication() के माध्यम से ऐप तक पहुँचते हैं, buttons["Login"] या textFields["email"] के माध्यम से तत्व ढूंढते हैं और क्रियाओं का अनुकरण करते हैं।

पहला E2E-परीक्षण लिखना: लॉगिन परिदृश्य

मान लीजिए, हमारे पास Email, Password फ़ील्ड और "Sign In" बटन वाला एक लॉगिन स्क्रीन है। लक्ष्य: यह जांचना कि सही डेटा दर्ज करने पर उपयोगकर्ता मुख्य स्क्रीन पर जाता है।

import XCTest\n\nclass LoginE2ETests: XCTestCase {\n    \n    let app = XCUIApplication()\n    \n    override func setUpWithError() throws {\n        continueAfterFailure = false\n        app.launch()\n    }\n    \n    func testSuccessfulLogin() throws {\n        // 1. तत्व ढूंढें\n        let emailField = app.textFields["emailTextField"]\n        let passwordField = app.secureTextFields["passwordTextField"]\n        let loginButton = app.buttons["signInButton"]\n        \n        // 2. उपयोगकर्ता क्रियाएँ\n        emailField.tap()\n        emailField.typeText("user@example.com")\n        \n        passwordField.tap()\n        passwordField.typeText("ValidPassword123")\n        \n        loginButton.tap()\n        \n        // 3. परिणाम जांचें\n        let dashboard = app.staticTexts["dashboardTitle"]\n        XCTAssertTrue(dashboard.waitForExistence(timeout: 5))\n    }\n}

महत्वपूर्ण बिंदु: waitForExistence(timeout:) का उपयोग करें — इसके बिना, यदि एनिमेशन या नेटवर्क अनुरोध में देरी होती है तो परीक्षण विफल हो सकता है। यह Swift के E2E परीक्षण का आधार है।

यह कोड क्यों विफल हो सकता है?

\n
• इनपुट फ़ील्ड पहला responder नहीं हो सकता — typeText से पहले .tap() जोड़ें।
\n
• बटन कीबोर्ड से ढका हो सकता है — app.keyboards.buttons["Return"].tap() का उपयोग करें।
\n
• टेक्स्ट लेबल स्थानीयकरण के आधार पर भिन्न हो सकते हैं — हमेशा Accessibility Identifier का उपयोग करें।
\n

Swift के लिए Page Object Model (POM): परीक्षणों को साफ बनाना

जब ऐप बड़ा होता है, परीक्षण गड़बड़ हो जाते हैं। समाधान — Page Object Model। हम प्रत्येक स्क्रीन के लिए अलग-अलग क्लास बनाते हैं जो तत्वों को खोजने और क्रियाओं के तर्क को समाहित करते हैं।

लॉगिन स्क्रीन के लिए उदाहरण:

// Lo