Unit test versus UI test in Xcode
The scope and tooling difference between test types.
Unit tests (XCTest) exercise code logic in-process and fast; UI tests (XCUITest) drive the app through the accessibility layer, slower and end-to-end.
WHAT THIS TESTS This confirms you understand the two layers of Xcode testing, their speed and reliability tradeoffs, and can pick the right tool for a given verification.
A GOOD ANSWER COVERS A unit test, written with the XCTest framework, runs inside the app's process and calls your code directly. It verifies a unit of logic, a function, struct, or class, in isolation, is fast, deterministic, and easy to run in large numbers. A UI test uses the XCUITest API, primarily XCUIApplication and XCUIElement queries, to launch the app as a separate process and drive it the way a user would, tapping buttons and typing, observing results through the accessibility layer. UI tests validate end-to-end flows across screens but are slower, more fragile, and depend on stable accessibility identifiers. The rule of thumb is to unit-test logic and use a small number of UI tests for critical journeys.
COMMON WRONG ANSWERS Saying UI tests can access internal variables directly; they cannot, they only see the UI via accessibility. Claiming unit tests can verify navigation between screens with real taps. Treating the two as interchangeable. Suggesting you should write mostly UI tests, ignoring the test pyramid.
LIKELY FOLLOW-UPS How the test pyramid argues for many unit tests and few UI tests. The role of accessibility identifiers in making UI tests robust. Where integration tests fit. How XCTestExpectation handles async. Why UI tests cannot import @testable internals.
ONE CONCRETE EXAMPLE A sorting algorithm is pure logic, so you write a unit test: call sort on a known unsorted array and XCTAssertEqual the result to the expected sorted array, plus edge cases like empty and single-element inputs; it runs in milliseconds. A login flow spans a username field, a password field, a button, and a navigation result, so you write a UI test: app.launch(), type into the fields by accessibility identifier, tap Sign In, and assert the home screen's element exists. The first verifies correctness of code; the second verifies the user-facing journey works.
Interview question
You want to verify that a pure sorting function returns correctly ordered output for many inputs. Which test type fits best and why?
- a.A UI test, because sorting affects what the user sees on screen
- b.A unit test, because it calls the function directly, runs fast, and isolates logicCorrect
- c.A UI test, because it exercises the app exactly as a user would
- d.Either is equally appropriate since both can call the function
Why? this is the answer
Sorting is pure logic best verified by a fast, in-process unit test that calls the function directly across many cases. A UI test cannot call internal functions directly and would be needlessly slow and brittle for this.
Just read this? Test yourself on what you have been reading.
Read the original → developer.apple.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ios — each one lists the topics its interview covers.
See open roles