XCTest: کلیدی تصورات، XCTestCase کلاسیں اور ٹیسٹ لکھنا

XCTest کیا ہے؟

XCTest یونٹ، انٹیگریشن اور UI جانچ کے لیے ایک فریم ورک ہے جسے Apple نے تیار کیا ہے اور ورژن 5.0 (2013) سے Xcode میں شامل ہے۔ XCTest نے OCUnit (SenTestingKit) کی جگہ لے لی اور جدید Swift API فراہم کیا جس میں غیر متزامن ٹیسٹ، کارکردگی کے ٹیسٹ اور Xcode Server انضمام کی حمایت شامل ہے۔ 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 صارف کی وضاحت کردہ خصوصیات کے ذریعے وضاحت شامل کرنے کی بھی اجازت دیتا ہے۔

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 میں ٹیسٹ پلان ترتیبات کے مطابق کارکردگی کے ٹیسٹوں کو گروپ کرنے کی اجازت دیتا ہے: ڈیبگ/ریلیز، مختلف آلات، 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 میں ٹیسٹ کے اہداف یونٹ ٹیسٹ اور UI ٹیسٹ کے لیے الگ سے ترتیب دیے جاتے ہیں، جو انہیں آزادانہ طور پر چلانے کی اجازت دیتا ہے۔ Xcode میں اسکیمیں بلڈ کنفیگریشن اور چلائے جانے والے ٹیسٹوں کے سیٹ کا انتظام کرتی ہیں۔

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% کوریج نافذ کرنے سے “خالی ٹیسٹ” پیدا ہوتے ہیں جو منطق کی تصدیق نہیں کرتے بلکہ صرف کوڈ پر عملدرآمد کرتے ہیں۔