Testing in iOS

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?

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!

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.

XCUIApplication is a proxy for the application that you are testing. It can access the various elements of your application using XCUIElementQuery.

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.