XCTest: मुख्य अवधारणाएँ, XCTestCase क्लासेज़ और टेस्ट लेखन

XCTest क्या है?

XCTest Apple द्वारा विकसित यूनिट, इंटीग्रेशन और UI परीक्षण के लिए एक फ्रेमवर्क है जो संस्करण 5.0 (2013) से Xcode में निर्मित है। XCTest ने OCUnit (SenTestingKit) को बदल दिया और अतुल्यकालिक टेस्ट, प्रदर्शन टेस्ट और Xcode Server एकीकरण के समर्थन के साथ Swift में एक आधुनिक API प्रदान किया। Swift.org (2024) के अनुसार, XCTest सभी Apple प्रोजेक्ट्स में परीक्षण की नींव है, जिसमें Swift Package Manager भी शामिल है, जो स्व-सत्यापन के लिए XCTest का उपयोग करता है।

XCTest Xcode Test Navigator और Report Navigator के साथ काम करता है, जो टेस्ट ट्री, रन का इतिहास दिखाते हैं और बिल्ड के बीच परिणामों की तुलना करते हैं। Test Navigator कोड को संशोधित किए बिना एक टेस्ट, टेस्ट का समूह या पूरा सूट चलाने की अनुमति देता है। परिणाम हरे (पास), लाल (फेल) और पीले (स्किप) आइकन के साथ प्रदर्शित होते हैं। Apple WWDC (2024) के अनुसार, Xcode 16 ने कई सिम्युलेटर का उपयोग करके समानांतर टेस्ट निष्पादन में 40% सुधार किया।

XCTest प्लेटफ़ॉर्म का समर्थन करता है: iOS 8.0+, macOS 10.10+, watchOS 2.0+, tvOS 9.0+. प्रत्येक प्लेटफ़ॉर्म में समान API है, जो क्रॉस-प्लेटफ़ॉर्म टेस्ट लेखन की अनुमति देता है। Swift Testing — Apple का एक नया फ्रेमवर्क (2024 में घोषित) — भविष्य में XCTest का पूरक होगा लेकिन इसे पूरी तरह से प्रतिस्थापित नहीं करेगा। XCTest Apple इकोसिस्टम में प्राथमिक परीक्षण फ्रेमवर्क बना हुआ है।

XCTestCase — टेस्ट के लिए आधार क्लास

XCTestCase आधार क्लास है जिससे XCTest में सभी टेस्ट क्लासेज़ इनहेरिट करती हैं। यह टेस्ट जीवनचक्र प्रदान करता है: प्रत्येक टेस्ट से पहले `setUp()` कहा जाता है, प्रत्येक टेस्ट के बाद `tearDown()` कहा जाता है। setUp का उपयोग ऑब्जेक्ट और मॉक को आरंभ करने के लिए किया जाता है, tearDown संसाधनों को साफ करने के लिए। setUpWithError और tearDownWithError प्रत्येक टेस्ट में try-catch के बिना आरंभीकरण त्रुटियों को संभालने की अनुमति देते हैं।

प्रत्येक विधि जिसका नाम `test` से शुरू होता है, स्वचालित रूप से Xcode द्वारा एक टेस्ट के रूप में पहचाना जाता है। वैकल्पिक रूप से, `@Test` मैक्रो (Swift Testing) का उपयोग किया जा सकता है। टेस्ट के नाम वर्णनात्मक होने चाहिए: `testLoginWithValidCredentials` `testLogin1` से बेहतर है। टिप्पणियों के माध्यम से टेस्ट का दस्तावेज़ीकरण एक अच्छी प्रथा है, लेकिन Xcode User-Defined Attributes के माध्यम से विवरण जोड़ने की भी अनुमति देता है।

import XCTest

class UserServiceTests: XCTestCase {

    var sut: UserService!
    var mockSession: MockURLSession!

    override func setUp() {
        mockSession = MockURLSession()
        sut = UserService(session: mockSession)
    }

    override func tearDown() {
        sut = nil
        mockSession = nil
    }

    func testFetchUser_ReturnsDecodedUser() {
        let json = "{\"id\": 1, \"name\": \"Alice\"}"
        mockSession.setResponse(json)
        let user = try await sut.fetchUser(id: 1)
        XCTAssertEqual(user.name, "Alice")
    }
}

उपरोक्त उदाहरण मानक XCTestCase संरचना प्रदर्शित करता है। sut (सिस्टम अंडर टेस्ट) परीक्षण किए जा रहे ऑब्जेक्ट के लिए एक नामकरण परंपरा है। MockURLSession वास्तविक नेटवर्क को बदल देता है, जिससे UserService को अलग-थलग करके परीक्षण किया जा सकता है। “एक टेस्ट — एक एसर्शन” का सिद्धांत डीबगिंग को सरल बनाता है: यदि कोई टेस्ट विफल होता है, तो डेवलपर तुरंत जान जाता है कि कौन सी कार्यक्षमता टूटी है। प्रत्येक XCTestCase टेस्ट को एक परिदृश्य या एक एसर्शन को सत्यापित करना चाहिए।

XCTest में एसर्शन

मूल एसर्शन समूह

XCTAssertTrue और XCTAssertFalse बूलियन मानों की जाँच के लिए मूल एसर्शन हैं। XCTAssertTrue(expression) पास होता है यदि expression == true। XCTAssertEqual Equatable लागू करने वाले सभी प्रकारों के समर्थन के साथ दो मानों की समानता की जाँच करता है। फ़्लोटिंग-पॉइंट संख्याओं के लिए, गणना सटीकता को ध्यान में रखने के लिए accuracy पैरामीटर के साथ XCTAssertEqual का उपयोग किया जाता है। Google Testing Blog (2024) के अनुसार, XCTAssertEqual एक सामान्य टेस्ट सूट में सभी जाँचों का 70% कवर करता है।

Nil एसर्शन और त्रुटियाँ

XCTAssertNil और XCTAssertNotNil nil के लिए वैकल्पिक मानों की जाँच करते हैं। Swift में ये एसर्शन महत्वपूर्ण हैं, जहाँ वैकल्पिक प्रकारों का व्यापक रूप से उपयोग किया जाता है। XCTAssertThrowsError सत्यापित करता है कि कोड अपेक्षित त्रुटि फेंकता है। XCTUnwrap एक एसर्शन है जो एक वैकल्पिक मान को अनरैप करता है और यदि मान nil है तो स्पष्ट संदेश के साथ विफल होता है। XCTAssertEqual के माध्यम से स्ट्रिंग तुलना शाब्दिक तुलना का उपयोग करती है, शब्दार्थ नहीं। XCTAssertNoThrow यह सत्यापित करने के लिए युग्मित एसर्शन है कि कोड त्रुटि नहीं फेंकता है।

XCTestExpectation और अतुल्यकालिक टेस्ट

XCTestExpectation अतुल्यकालिक कोड के परीक्षण के लिए एक तंत्र है। टेस्ट एक वर्णनात्मक नाम के साथ एक अपेक्षा बनाता है, इसे एक अतुल्यकालिक ऑपरेशन में भेजता है, और `wait(for:timeout:)` कहता है। यदि अपेक्षा टाइमआउट के भीतर पूरी नहीं होती है, तो टेस्ट विफल हो जाता है। टाइमआउट डिफ़ॉल्ट रूप से 10 सेकंड है, लेकिन तेज़ संचालन के लिए समग्र परीक्षण समय को गति देने के लिए 1–3 सेकंड सेट करने की अनुशंसा की जाती है।

XCTWaiter wait(for:timeout:) का अधिक लचीला विकल्प है। XCTWaiter कई अपेक्षाओं की प्रतीक्षा करने, निष्पादन क्रम कॉन्फ़िगर करने और प्रोग्रामेटिक रूप से टाइमआउट संभालने की अनुमति देता है। wait के विपरीत, XCTWaiter `XCTWaiter.Result` लौटाता है, जिसका विश्लेषण किया जा सकता है। डेलीगेट XCTWaiterDelegate अपेक्षा क्रम उल्लंघन और टाइमआउट के बारे में सूचित करता है।

func testAsyncLogin() {
    let expectation = XCTestExpectation(description: "login")
    var resultUser: User?

    sut.login(email: "a@b.com", password: "123") { user in
        resultUser = user
        expectation.fulfill()
    }

    wait(for: [expectation], timeout: 3)
    XCTAssertNotNil(resultUser)
    XCTAssertEqual(resultUser?.email, "a@b.com")
}

उदाहरण में, XCTestExpectation का उपयोग अतुल्यकालिक लॉगिन के परीक्षण के लिए किया जाता है। कॉलबैक क्लोज़र के अंदर fulfill() कहा जाता है, जो संकेत देता है कि अतुल्यकालिक ऑपरेशन पूरा हो गया है। यदि 3 सेकंड के भीतर fulfill() नहीं कहा जाता है, तो टेस्ट टाइमआउट के साथ विफल हो जाता है। सफल प्रतीक्षा के बाद, परिणाम सत्यापित करने के लिए एसर्शन किए जाते हैं। कई अपेक्षाओं को एक सरणी के रूप में पारित किया जा सकता है और सभी के पूरा होने की प्रतीक्षा की जा सकती है।

XCTest के साथ प्रदर्शन टेस्ट

measure(metrics:) प्रदर्शन टेस्ट बनाने के लिए XCTestCase विधि है। measure के अंदर कोड ब्लॉक लगातार 10 बार चलता है, और XCTest सांख्यिकी एकत्र करता है: औसत समय, माध्यिका, मानक विचलन। मेट्रिक्स ट्रैक किए गए मेट्रिक्स की एक सरणी है: XCTClockMetric (समय), XCTMemoryMetric (मेमोरी), XCTStorageMetric (डिस्क), और XCTCPUMetric (प्रोसेसर)। Apple WWDC (2024) के अनुसार, XCTCPUMetric के साथ प्रदर्शन टेस्ट एल्गोरिदम में प्रतिगमन का पता लगाने के लिए उपयोगी हैं।

प्रदर्शन टेस्ट के लिए बेसलाइन Xcode Test Plan में सेट की जाती है। यदि निष्पादन समय बेसलाइन से एक निर्धारित प्रतिशत (डिफ़ॉल्ट 10%) से अधिक है, तो टेस्ट विफल माना जाता है। बेसलाइन को यह पुष्टि करने के बाद मैन्युअल रूप से अपडेट किया जाता है कि प्रदर्शन परिवर्तन अपेक्षित है। Xcode में Test Plan कॉन्फ़िगरेशन के अनुसार प्रदर्शन टेस्ट को समूहित करने की अनुमति देता है: debug/release, विभिन्न डिवाइस, विभिन्न iOS संस्करण।

func testArraySortPerformance() {
    let numbers = (1...10000).shuffled()
    measure(metrics: [XCTClockMetric()]) {
        let _ = numbers.sorted()
    }
}

यह प्रदर्शन टेस्ट 10,000 तत्वों की एक सरणी के सॉर्टिंग समय को मापता है। XCTClockMetric वास्तविक निष्पादन समय को कैप्चर करता है। यदि सॉर्टिंग एल्गोरिदम बदलने के बाद समय 10% या अधिक बढ़ जाता है, तो टेस्ट प्रतिगमन का संकेत देगा। XCTest प्रदर्शन टेस्ट विशेष रूप से उपयोगी हैं: डेटा प्रोसेसिंग एल्गोरिदम, UI घटक रेंडरिंग, डेटाबेस संचालन और नेटवर्क अनुरोधों के लिए।

टेस्ट संगठन और CI/CD एकीकरण

टेस्ट प्रोजेक्ट संरचना

टेस्ट प्रोजेक्ट संरचना XCTest में परंपरा का पालन करती है: प्रति क्लास एक टेस्ट फ़ाइल, एक अलग `<TargetName>Tests` निर्देशिका में रखी जाती है। फ़ाइल नाम `Tests` प्रत्यय के साथ परीक्षण की गई क्लास के नाम से मेल खाते हैं: `UserService.swift` → `UserServiceTests.swift`. Xcode में Test Targets यूनिट टेस्ट और UI टेस्ट के लिए अलग-अलग कॉन्फ़िगर किए जाते हैं, जिससे उन्हें स्वतंत्र रूप से चलाया जा सकता है। Xcode में Schemes बिल्ड कॉन्फ़िगरेशन और चलाए जाने वाले टेस्ट के सेट का प्रबंधन करती हैं।

CI/CD एकीकरण

Xcode Cloud और GitHub Actions `xcodebuild test -scheme App -testPlan SmokeTest` के माध्यम से XCTest चलाने का समर्थन करते हैं। CI पाइपलाइन में शामिल है: बिल्ड → यूनिट टेस्ट चलाना → UI टेस्ट चलाना → रिपोर्ट प्रकाशित करना। JUnit रिपोर्ट `-resultBundlePath` विकल्प के साथ `xcodebuild` के माध्यम से उत्पन्न होती है और इसे किसी भी CI टूल में आयात किया जा सकता है। कोड कवरेज XCTest की एक अंतर्निहित सुविधा है जो दिखाती है कि कोड की कौन सी पंक्तियाँ टेस्ट द्वारा कवर की गई हैं। प्रोडक्शन कोड के लिए न्यूनतम कवरेज सीमा महत्वपूर्ण व्यावसायिक तर्क के लिए 70% है।

Xcode Cloud और GitHub Actions `xcodebuild test -scheme App -testPlan SmokeTest` के माध्यम से XCTest चलाने का समर्थन करते हैं। CI पाइपलाइन में शामिल है: बिल्ड → यूनिट टेस्ट चलाना → UI टेस्ट चलाना → रिपोर्ट प्रकाशित करना। JUnit रिपोर्ट `-resultBundlePath` विकल्प के साथ `xcodebuild` के माध्यम से उत्पन्न होती है और इसे किसी भी CI टूल में आयात किया जा सकता है। Bitrise और Jenkins के पास XCTest के लिए तैयार चरण हैं।

कोड कवरेज XCTest की एक अंतर्निहित सुविधा है जो दिखाती है कि कोड की कौन सी पंक्तियाँ टेस्ट द्वारा कवर की गई हैं। Xcode कवरेज को हरे (कवर), लाल (कवर नहीं) और पीले (आंशिक रूप से कवर) में प्रदर्शित करता है। प्रोडक्शन कोड कवरेज के लिए न्यूनतम सीमा महत्वपूर्ण व्यावसायिक तर्क के लिए 70% है। Google Testing Blog (2024) के अनुसार, सभी मॉड्यूल के लिए 80% कवरेज लागू करने से “खाली टेस्ट” होते हैं जो तर्क को सत्यापित नहीं करते बल्कि केवल कोड निष्पादित करते हैं।