Xcode में साझा XCTest हेल्पर को कॉल करने वाला टेस्ट हाइलाइट करवाने के लिए, हेल्पर को डिफ़ॉल्ट #filePath और #line पैरामीटर दें और दोनों को उसके assertions तक फ़ॉरवर्ड करें। इस गाइड में समाधान, नेस्टेड हेल्पर और Swift Testing के समकक्ष तरीके दिखाए गए हैं।

Xcode हेल्पर को हाइलाइट क्यों करता है?

साझा assertion से स्रोत का एक और स्थान जुड़ जाता है। टेस्ट आपके हेल्पर को कॉल करता है और हेल्पर XCTest assertion को। अगर वह assertion अपने डिफ़ॉल्ट लोकेशन आर्ग्युमेंट इस्तेमाल करता है, तो रिपोर्ट किया गया स्थान हेल्पर के भीतर का assertion होता है। Apple, XCTAssertEqual और XCTFail, दोनों के लिए file: StaticString = #filePath और line: UInt = #line दस्तावेज़ करता है।

हेल्पर की सीमा पर कॉल करने वाले का स्थान कैप्चर करें, फिर उन मानों को आगे पास करें। Swift के स्रोत-स्थान डिफ़ॉल्ट कॉल साइट को कैप्चर करते हैं; Swift प्रोजेक्ट इस व्यवहार को SE-0274: संक्षिप्त मैजिक फ़ाइल नाम में समझाता है। Apple, Swift Testing पर माइग्रेट करें में XCTest हेल्पर का यही तरीका दिखाता है और बताता है कि Xcode विफलता का श्रेय हेल्पर कॉल को देता है।

Mac पर Xcode में काम करने वाले डेवलपर के लिए, ठोस लक्ष्य यह है कि दोबारा इस्तेमाल किए जा सकने वाले चेक बनाए रखें और हर विफलता को संबंधित टेस्ट इनपुट तक वापस ले जाएँ। नीचे दिए गए उदाहरणों में केवल छोटे पूर्णांक ऐरे इस्तेमाल किए गए हैं। इन्हें चलाने के लिए ऐप मॉडल, सेवा का विकल्प, डाउनलोड की गई निर्भरता या नेटवर्क ऐक्सेस की ज़रूरत नहीं है।

XCTest हेल्पर में कॉलर-लोकेशन पैरामीटर जोड़ें

मौजूदा macOS यूनिट टेस्ट टार्गेट इस्तेमाल करें। अगर प्रोजेक्ट को इसकी ज़रूरत हो, तो File > New > Target चुनें, Test फ़िल्टर करें और Unit Testing Bundle चुनें। टेस्ट फ़ाइल जोड़ने के लिए File > New > New File From Template चुनें और XCTest Unit Test चुनें। Apple ने अपने Xcode प्रोजेक्ट में टेस्ट जोड़ना में ये रास्ते दस्तावेज़ किए हैं।

यह पूरी टेस्ट फ़ाइल उस यूनिट टेस्ट टार्गेट में रखें। दूसरा टेस्ट जानबूझकर गलत अपेक्षित कुल मान देता है, ताकि आप विफलता का स्थान देख सकें।

import XCTest

private func assertTotal(
    _ values: [Int],
    equals expected: Int,
    file: StaticString = #filePath,
    line: UInt = #line
) {
    let actual = values.reduce(0, +)
    XCTAssertEqual(
        actual,
        expected,
        "Unexpected total for \(values)",
        file: file,
        line: line
    )
}

final class TotalHelperTests: XCTestCase {
    func testMatchingTotal() {
        assertTotal([2, 3, 4], equals: 9)
    }

    func testDeliberatelyIncorrectTotal() {
        assertTotal([2, 3, 4], equals: 10)
    }
}

ज़रूरी बातें हैं पैरामीटर के टाइप, डिफ़ॉल्ट और उन्हें स्पष्ट रूप से आगे पास करना। StaticString और UInt, XCTest के assertion सिग्नेचर से मेल खाते हैं। #filePath और #line को सीधे हेल्पर के डिफ़ॉल्ट में रखें। इसके बाद टेस्ट, लोकेशन आर्ग्युमेंट दिए बिना हेल्पर को कॉल करता है। दस्तावेज़ किए गए XCTAssertEqual पैरामीटर देखें।

यहाँ अंकगणित केवल उदाहरण के लिए है: 2 + 3 + 4, 9 है, इसलिए पहली तुलना मेल खाती है और दूसरी नहीं। इन अंकगणितीय मामलों को Python से स्थानीय रूप से जाँचा गया। शोध परिवेश में Swift executable उपलब्ध नहीं था, इसलिए Swift उदाहरणों का निरीक्षण किया गया, लेकिन उन्हें यहाँ कंपाइल या रन नहीं किया गया।

स्थान और टेस्ट का नतीजा सत्यापित करें

Product > Test चुनें, या टेस्ट की घोषणा के पास मौजूद प्ले कंट्रोल से अलग-अलग टेस्ट रन करें। इसके बाद Test navigator में विफल टेस्ट चुनें और डायग्नॉस्टिक देखें। Apple, टेस्ट चलाना और नतीजों को समझना में इन कंट्रोल और विफलता के विवरण की जानकारी देता है।

इस उदाहरण में दो अलग नतीजे सत्यापित करें: testDeliberatelyIncorrectTotal() विफल होता है और उसका assertion डायग्नॉस्टिक assertTotal([2, 3, 4], equals: 10) कॉल की ओर इशारा करता है। कॉलर को श्रेय देने का यह अपेक्षित व्यवहार Apple के दिखाए गए फ़ॉरवर्डिंग तरीके के अनुरूप है। जाँच करने के बाद 10 को 9 में बदलें और टेस्ट दोबारा रन करें; जानबूझकर रखा गया बेमेल अंतिम टेस्ट सूट से हटा देना चाहिए।

अगर डायग्नॉस्टिक अब भी हेल्पर के भीतर के स्थान की ओर इशारा करता है, तो आखिरी assertion कॉल देखें। केवल लोकेशन पैरामीटर घोषित करना पर्याप्त नहीं है; विफलता दर्ज करने वाली जगह पर हेल्पर को file: file या line: line छोड़ना नहीं चाहिए।

हर हेल्पर लेयर में स्थान बनाए रखें

नेस्टेड हेल्पर में भी वही स्पष्ट फ़ॉरवर्डिंग चाहिए। मान लें कि टेस्ट एक डोमेन हेल्पर को कॉल करता है, जो आगे निचले स्तर के assertion हेल्पर को कॉल करता है। अगर बाहरी हेल्पर लोकेशन आर्ग्युमेंट छोड़ देता है, तो निचले स्तर का हेल्पर बीच वाली कॉल साइट कैप्चर कर लेगा।

भाषा की इस सीमा पर ध्यान देना ज़रूरी है: स्रोत-स्थान डिफ़ॉल्ट मनमाने हेल्पर कॉल के ज़रिए अपने आप आगे नहीं जाते। SE-0285: संक्षिप्त मैजिक फ़ाइल स्ट्रिंग पर जाना आसान बनाना इन डिफ़ॉल्ट के गैर-संक्रमणशील व्यवहार पर स्पष्ट चर्चा करता है।

नीचे दी गई वैकल्पिक टेस्ट फ़ाइल पूरी है। इसमें एक हेल्पर दूसरे हेल्पर को कॉल करता है और मूल टेस्ट स्थान बनाए रखता है।

import XCTest

private func assertIntegerEqual(
    _ actual: Int,
    _ expected: Int,
    file: StaticString = #filePath,
    line: UInt = #line
) {
    XCTAssertEqual(actual, expected, file: file, line: line)
}

private func assertRowTotal(
    _ row: [Int],
    equals expected: Int,
    file: StaticString = #filePath,
    line: UInt = #line
) {
    assertIntegerEqual(
        row.reduce(0, +),
        expected,
        file: file,
        line: line
    )
}

final class NestedTotalHelperTests: XCTestCase {
    func testRowTotal() {
        assertRowTotal([2, 3, 4], equals: 9)
    }
}

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

क्या विफलता रिपोर्ट करने से कॉल करने वाला टेस्ट रुक जाता है?

विफलता का श्रेय और कंट्रोल फ़्लो अलग-अलग निर्णय हैं। XCTest का continueAfterFailure डिफ़ॉल्ट रूप से true होता है, इसलिए विफल assertion के बाद आम तौर पर निष्पादन जारी रहता है। रिपोर्ट की गई फ़ाइल और लाइन बदलने से यह गुण नहीं बदलता। Apple इस व्यवहार को continueAfterFailure में दस्तावेज़ करता है।

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

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

Swift Testing में समर्थित स्रोत स्थान इस्तेमाल करें

Swift Testing टेस्ट द्वारा कॉल किए गए हेल्पर के लिए, स्पष्ट SourceLocation के साथ #expect इस्तेमाल करें। Apple, sourceLocation को उस स्थान के रूप में दस्तावेज़ करता है जिससे अपेक्षाएँ और समस्याएँ जोड़ी जाती हैं। वह यह भी कहता है कि गलत शर्त, मौजूदा टास्क में चल रहे टेस्ट के लिए समस्या दर्ज करती है। expect(_:_:sourceLocation:) देखें।

इस पूरी वैकल्पिक फ़ाइल के लिए Swift Testing चाहिए, जो Xcode 16 और Swift 6.0 के साथ उपलब्ध है। यह लोकेशन के चारों हिस्सों को अलग-अलग डिफ़ॉल्ट के रूप में कैप्चर करती है, फिर दस्तावेज़ किए गए SourceLocation इनिशियलाइज़र से ऑब्जेक्ट बनाती है।

import Testing

private func expectTotal(
    _ values: [Int],
    equals expected: Int,
    fileID: String = #fileID,
    filePath: String = #filePath,
    line: Int = #line,
    column: Int = #column
) {
    let location = SourceLocation(
        fileID: fileID,
        filePath: filePath,
        line: line,
        column: column
    )
    let actual = values.reduce(0, +)
    #expect(actual == expected, sourceLocation: location)
}

@Test func matchingTotal() {
    expectTotal([2, 3, 4], equals: 9)
}

@Test func deliberatelyIncorrectTotal() {
    expectTotal([2, 3, 4], equals: 10)
}

इनिशियलाइज़र के लिए सही फ़ॉर्मैट वाली, खाली न होने वाली फ़ाइल ID और धनात्मक लाइन और कॉलम नंबर ज़रूरी हैं। कंपाइलर से मिले हिस्सों को कैप्चर करने से इन मानों का अनुमान लगाने की ज़रूरत नहीं पड़ती। इन हेल्पर को नेस्ट करते समय, चारों कैप्चर किए गए आर्ग्युमेंट आगे पास करें, ठीक वैसे ही जैसे XCTest वाला तरीका अपने दो आर्ग्युमेंट आगे पास करता है। फिर से, श्रेय देने की पुष्टि के बाद जानबूझकर रखी गई 10 अपेक्षा ठीक करें।

XCTest और Swift Testing एक हेल्पर साझा करें, तो क्या बदलता है?

दोनों फ़्रेमवर्क एक ही टेस्ट बंडल में साथ मौजूद रह सकते हैं, लेकिन फ़्रेमवर्क की सीमाएँ पार करने वाले हेल्पर के लिए टूलचेन संस्करण के अनुसार ध्यान रखना पड़ता है। Apple की मौजूदा माइग्रेशन गाइड आपसी संगतता और उसके डिफ़ॉल्ट दस्तावेज़ करती है: Swift 6.4 से पुराने टूलचेन none इस्तेमाल करते हैं; Swift 6.4 या बाद के संस्करण में, पहले के tools version घोषित करने वाले पैकेजों के लिए डिफ़ॉल्ट limited और tools version 6.4 या बाद का घोषित करने वाले पैकेजों के लिए complete होता है।

आपसी संगतता मोड Swift Testing टेस्ट के भीतर XCTest assertion की विफलता
none दूसरी लाइब्रेरी की समस्या अनदेखी की जाती है
limited आधुनिकीकरण के मार्गदर्शन के साथ चेतावनी के रूप में रिपोर्ट की जाती है
complete आधुनिकीकरण के मार्गदर्शन के साथ विफलता का स्तर बनाए रखती है
strict fatalError के ज़रिए रिपोर्ट की जाती है

इन मोड से समझ आता है कि हेल्पर सही टेक्स्ट रिपोर्ट करने के बावजूद Swift Testing टेस्ट को पास कैसे छोड़ सकता है। Apple का WWDC26 माइग्रेशन सत्र यही नतीजा दिखाता है, फिर विफलता का स्तर बनाए रखने के लिए Test Execution के तहत टेस्ट प्लान की आपसी संगतता सेटिंग को Complete पर बदलता है। इस सुविधा पर भरोसा करने से पहले अपने इंस्टॉल किए गए टूलचेन की जाँच करें।

पुराने टूलचेन में, हर फ़्रेमवर्क के लिए assertion रिपोर्टिंग उसी फ़्रेमवर्क के तरीके से रखें और उसके नीचे की तयशुदा गणना साझा करें। समर्थित आपसी संगतता कॉन्फ़िगरेशन में, Apple हेल्पर के XCTFail को Swift Testing के Issue.record से बदलने का तरीका भी दिखाता है। इस माइग्रेशन के दौरान स्रोत-स्थान की फ़ॉरवर्डिंग भी बनाए रखनी होगी।

बाकी समस्या का निदान करें

आपको क्या दिखता है आगे क्या जाँचें
विफलता assertion हेल्पर के भीतर दिखाई देती है पुष्टि करें कि assertion को कैप्चर किए गए लोकेशन आर्ग्युमेंट मिलते हैं
विफलता बाहरी हेल्पर के भीतर दिखाई देती है पुष्टि करें कि बाहरी हेल्पर अपने कॉलर का स्थान आगे पास करता है
XCTest assertion के बावजूद Swift Testing टेस्ट पास होता है टूलचेन का समर्थन और आपसी संगतता मोड जाँचें
XCTest assertion के विफल होने के बाद भी कोड चलता है अपेक्षित कंट्रोल फ़्लो और continueAfterFailure जाँचें
रन में कोई उदाहरण टेस्ट नहीं दिखता पुष्टि करें कि फ़ाइल यूनिट टेस्ट टार्गेट में है और सक्रिय टेस्ट प्लान में शामिल है

टेस्ट खोजने और चुनने के बारे में Apple की टेस्ट सेटअप गाइड और टेस्ट निष्पादन गाइड, टेस्ट टार्गेट और सक्रिय प्लान की जानकारी देती हैं। अलग-अलग फ़्रेमवर्क के बीच पास होने की समस्या में, लोकेशन आर्ग्युमेंट बदलने से पहले ऊपर दिए गए दस्तावेज़ित आपसी संगतता नियम देखें।

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

स्रोत