Who is this for?
This course is intended for developers who have little to no experience using XCTest, Apple’s Xcode-based testing framework.
In the first part, you’ll use the Swift Package Manager (SPM) to examine the basics of testing, without the overhead of an app. You’ll build up a small library of Swift extensions, and learn the test-driven development cycle.
In part two, you’ll explore asynchronous testing in the context of an app that uses Model-View-Controller-Networking architecture. And you’ll try out test doubles, to see how they can reduce the time taken for testing.
The final part is on UI testing. You’ll write code that automates virtual interaction with onscreen elements, and you’ll learn to generate that code with recorded actions as well.
- Unit Testing
- Asynchronous Testing
- UI Testing
- Test Assertions
- Code Coverage
- Test Doubles (Fakes, Stubs, Mocks)
- Access Control
- Error Handling
- Swift Package Manager
- Protocol Inheritance
Part 1: Synchronous Unit Testing
There’s a lot to be said for the power of automated testing. In this course, that means unit tests, and their counterpart, UI tests.
“Test cases” are groups of related test methods. They exist within test targets, which have two ways to access code from other modules.
Your tests need to have some potential to fail, or you can’t be confident that your testable code is doing what you want it to. Enter XCTest assertions.
Create a test case which verifies that a FloatingPoint extension does in fact tell you if a floating point number is an integer.
XCTAssertEqual compares two Equatable arguments. In this episode, you’ll rely on it to add a “first” property to Sequences.
Code Coverage in Xcode details how much of your code is tested. We’ll explore how it can help write versatile, useful extensions, using Developer Documentation.
Test-Driven Development, or TDD for short, is a methodology to develop software by iteratively making many small changes backed by tests.
Test-Driven Development boils down to a simple process: the Red-Green-Refactor Cycle. Red is a state of test failure, and Green, test success.
Using the red-green-refactor cycle, revisit your Bool initializer, adding support for other types of integers.
The fundamental skills of testing in iOS are under your belt. When should you use the tools you’ve learned?
Part 2: Asynchronous Unit Testing
With asynchronous testing, you’ll still be writing similar assertion-based code, but you’ll be able to deal with situations where there’s a delay involved.
XCTestExpectation is a class that represents an expected outcome in an asynchronous test. Making use of its main features boils down to three lines of code.
Networking operations are an extremely common place to encounter errors. Here you’ll focus on ones native to Swift.
Get some practice writing your own asynchronous URLSession-based test. You’ll be expecting decoding errors!
Test doubles, such as fakes, mocks, stubs, and dummies, can help you reduce how many of your tests need to run asynchronously.
Now, you can unit test code, whether it’s asynchronous or not. And whether it throws a ton of errors at you, or not!
Part 3: UI Testing
UI testing is generally even slower than asynchronous network testing. But sometimes, it’s the best way to guarantee that your app is working as desired.
Record a UI Test
XCUIApplication is a proxy for the application that you are testing. It can access the various elements of your application using XCUIElementQuery.
Refactor a UI Test
In the last episode, you generated some code to automatically carry out a UI action. In this episode, you’ll refactor that code for creating an actual UI test.
XCUIElementTypeQueryProvider provides ready-made queries which return objects of a specific type. But there’s greater control to be had for accessing elements.
Modify a UI test that currently only supports iPhones, to work correctly on all iOS devices, in all orientations.
You’re ready to write test code for your own projects! Let’s go over some further resources, for when you’d like to learn more about testing.