XCTest framework in iOS Swift - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ ui_behavior

intermediate

What happens when a failing XCTAssert is encountered?

In an XCTest case, what is the behavior when an XCTAssert condition fails during a test method execution?

iOS Swift

func testExample() {
  XCTAssert(1 + 1 == 3)
  print("This line is reached")
}

A The test continues running, prints the message, but marks as failed at the end.

B The test immediately stops and marks as failed; the print statement is not executed.

C The test passes because print executes, ignoring the failed XCTAssert.

D The test crashes and stops the entire test suite.

💡 Hint

XCTAssert failures report errors but do not stop the test method immediately.

XCTAssert failures record a failure but allow the test method to continue running. This means subsequent lines execute, but the test is marked as failed overall.

📝 Syntax

intermediate

Which code correctly defines a test case class?

Select the correct Swift code snippet that defines a valid XCTestCase subclass with one test method.

A

class MyTests: XCTestCase {
  func exampleTest() {
    XCTAssertTrue(true)
  }
}

B

class MyTests: XCTestCase {
  func testExample() {
    XCTAssertTrue(true)
  }
}

C

class MyTests {
  func testExample() {
    XCTAssertTrue(true)
  }
}

D

class MyTests: XCTestCase {
  func testExample() {
    assert(true)
  }
}

💡 Hint

Test methods must start with 'test' and class must inherit XCTestCase.

Option B correctly inherits XCTestCase and defines a method starting with 'test'. Option B lacks inheritance, C method name does not start with 'test', D uses assert instead of XCTAssertTrue.

❓ lifecycle

advanced

What is the order of XCTest lifecycle methods?

Arrange the following XCTest lifecycle methods in the order they are called when running multiple test methods in a test case class.

A 2, 3, 1, 4

B 2, 1, 3, 4

C 1, 2, 4, 3

D 1, 2, 3, 4

💡 Hint

Class methods run once per class; instance methods run per test method.

setUp() class method runs once before all tests, setUp() instance method runs before each test, tearDown() instance method runs after each test, and tearDown() class method runs once after all tests.

🔧 Debug

advanced

Why does this test always pass even if the code is wrong?

Given the test below, why does it always pass even if the function under test returns wrong results? func testSum() { let result = sum(2, 3) XCTAssertEqual(result, 6) }

iOS Swift

func sum(_ a: Int, _ b: Int) -> Int {
  return a + b + 1
}

A The test passes because XCTAssertEqual is comparing to the wrong expected value (6 instead of 5).

B The test passes because sum function is correct and returns 6.

C The test passes because the test method is not named starting with 'test'.

D The test passes because XCTAssertEqual does not check equality.

💡 Hint

Check the expected value in XCTAssertEqual carefully.

The sum function incorrectly returns 6 for inputs 2 and 3 (should be 5), but the test expects 6, so the test passes even though the function under test returns wrong results.

🧠 Conceptual

expert

What is the purpose of XCTestExpectation in asynchronous tests?

Why do we use XCTestExpectation in XCTest when testing asynchronous code?

A To mock asynchronous functions without running real code.

B To automatically retry failed tests multiple times for flaky network calls.

C To pause the test until the asynchronous operation completes or times out, ensuring correct test timing.

D To speed up test execution by skipping asynchronous code.

💡 Hint

Think about how XCTest knows when async code finishes.

XCTestExpectation allows the test to wait for async code to finish or timeout, so tests can verify results after asynchronous operations complete.

Practice

1. What is the main purpose of the XCTest framework in iOS development?

easy

A. To manage app navigation between screens

B. To write automated tests that check app behavior

C. To design user interfaces visually

D. To optimize app performance during runtime

Solution

1. Step 1: Understand XCTest role

   XCTest is designed to help developers write tests that automatically verify if the app works as expected.

2. Step 2: Compare options with XCTest purpose

   Only To write automated tests that check app behavior describes writing automated tests, which matches XCTest's main use.

3. Final Answer:

   To write automated tests that check app behavior -> Option B

4. Quick Check:

   XCTest = Automated testing [OK]

Hint: XCTest is for testing, not UI or navigation [OK]

Common Mistakes:

• Confusing XCTest with UI design tools
• Thinking XCTest manages app navigation
• Assuming XCTest improves runtime speed

2. Which of the following is the correct way to declare a test method inside an XCTestCase subclass?

easy

A. func TestExample() { }

B. func exampleTest() { }

C. func testExample() { }

D. test func example() { }

Solution

1. Step 1: Recall XCTest method naming rules

   Test methods must start with 'test' and be declared as functions with no parameters.

2. Step 2: Check each option

   func testExample() { } uses 'func testExample() { }' which follows the naming convention. Others either have wrong order, capitalization, or syntax.

3. Final Answer:

   func testExample() { } -> Option C

4. Quick Check:

   Test methods start with 'test' [OK]

Hint: Test methods must start with 'test' keyword [OK]

Common Mistakes:

• Starting method name without 'test'
• Capitalizing 'Test' instead of 'test'
• Incorrect function syntax

3. What will be the result of this test method when run?

func testSum() {
  let result = 2 + 3
  XCTAssertEqual(result, 5)
}

medium

A. Test passes successfully

B. Test fails with assertion error

C. Test causes a compile-time error

D. Test is ignored and not run

Solution

1. Step 1: Evaluate the calculation

   The code calculates 2 + 3 and stores 5 in 'result'.

2. Step 2: Check the assertion

   XCTAssertEqual compares 'result' with 5, which is true, so the assertion passes.

3. Final Answer:

   Test passes successfully -> Option A

4. Quick Check:

   2 + 3 equals 5, assertion passes [OK]

Hint: If values match in XCTAssertEqual, test passes [OK]

Common Mistakes:

• Assuming test fails if no explicit pass message
• Confusing compile errors with assertion failures
• Thinking test is skipped without reason

4. Identify the error in this test method:

func testDivide() {
  let result = 10 / 0
  XCTAssertEqual(result, 0)
}

medium

A. XCTAssertEqual syntax is incorrect

B. Missing return type in function declaration

C. Test method name does not start with 'test'

D. Division by zero causes runtime crash

Solution

1. Step 1: Analyze the division operation

   Dividing 10 by 0 causes a runtime error (crash) because division by zero is undefined.

2. Step 2: Check other parts

   XCTAssertEqual syntax is correct, method name starts with 'test', and return type is not needed for test methods.

3. Final Answer:

   Division by zero causes runtime crash -> Option D

4. Quick Check:

   Division by zero crashes app [OK]

Hint: Division by zero always crashes at runtime [OK]

Common Mistakes:

• Thinking XCTAssertEqual syntax is wrong
• Believing test method needs return type
• Ignoring runtime errors from invalid math

5. You want to test a function that returns an optional string. Which assertion correctly verifies the function returns a non-nil value?

func testOptionalString() {
  let result = getOptionalString()
  // Which assertion to use?
}

hard

A. XCTAssertNotNil(result)

B. XCTAssertEqual(result, "")

C. XCTAssertTrue(result == nil)

D. XCTAssertFalse(result != nil)

Solution

1. Step 1: Understand the goal

   We want to check that 'result' is not nil, meaning it contains a value.

2. Step 2: Match assertion to goal

   XCTAssertNotNil checks that the value is not nil, which fits perfectly. Other options either check for empty string or nil incorrectly.

3. Final Answer:

   XCTAssertNotNil(result) -> Option A

4. Quick Check:

   Use XCTAssertNotNil to check non-nil values [OK]

Hint: Use XCTAssertNotNil to confirm value exists [OK]

Common Mistakes:

• Using XCTAssertEqual with empty string instead of nil check
• Confusing XCTAssertTrue with wrong condition
• Using XCTAssertFalse with incorrect logic