---
title: "XCTest | Skills We Assign For | Azendo"
description: "XCTest for iOS testing — unit and UI automation, keeping suites stable, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/xctest/"
---

[Skills](https://azendo.co/skills/) QA and delivery tooling 

# XCTest.

XCTest is Apple's testing framework, covering unit tests, performance measurement and UI automation for iOS and macOS applications. It is built into Xcode and runs in CI without additional tooling.

## Where XCTest fits on a long engagement.

XCTest covers three different activities under one name, and they behave very differently. Unit tests are fast and reliable; UI tests drive the application through the accessibility layer and are slow and comparatively fragile. Treating them as one testing strategy is how teams end up with a suite that nobody trusts.

The most useful discipline in UI tests is accessibility identifiers. Tests that locate elements by visible label break whenever copy changes or a translation lands; tests that use stable identifiers survive both. That single decision accounts for most of the difference between a durable UI suite and one that is disabled within a year.

## What an assigned team does with XCTest.

A flaky test is worse than no test, because it trains the team to ignore red builds. Once that habit exists, a genuine failure is dismissed along with the noise, and the suite has become a cost with no benefit.

Keeping a suite trustworthy is continuous maintenance rather than an initial build, and it is the reason dedicated [qa outsourcing](https://azendo.co/services/qa-engineering-and-test-automation/) capacity is scoped alongside development rather than assumed to be part of it.

## What we use XCTest for.

* Business logic covered fast Unit tests that run in seconds on every commit, where most of the real coverage should live.
* Critical journeys automated durably UI tests on sign-in and purchase, located by accessibility identifiers so copy changes do not break them.
* Performance regressions caught Measured tests failing when a critical path gets slower, rather than noticing after release.

## How XCTest capacity is assigned.

iOS test capacity sits inside development where it is unit-level coverage, and becomes separately assigned capacity where the suite is the constraint. How that line is drawn is set out in [how an assignment runs](https://azendo.co/how-it-works/).

## Roles we assign XCTest for

* [iOS Developer Mobile development](https://azendo.co/services/mobile-development/ios-developer/)

## Service lines it sits in

* [Mobile development](https://azendo.co/services/mobile-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in qa and delivery tooling

* [Xray — skill we assign for](https://azendo.co/skills/xray/)
* [Zephyr — skill we assign for](https://azendo.co/skills/zephyr/)
* [Jira — skill we assign for](https://azendo.co/skills/jira/)
* [TestRail — skill we assign for](https://azendo.co/skills/testrail/)
* [Jest — skill we assign for](https://azendo.co/skills/jest/)
* [React Testing Library — skill we assign for](https://azendo.co/skills/react-testing-library/)
* [Espresso — skill we assign for](https://azendo.co/skills/espresso/)
* [Detox — skill we assign for](https://azendo.co/skills/detox/)

## Tell us what your roadmap needs XCTest for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)