Hauser Test-Driven iOS Development with Swift

Create fully-featured and highly functional iOS apps by writing tests first
1. Auflage 2025
ISBN: 978-1-78588-004-9
Verlag: De Gruyter
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)

E-Book, Englisch, 218 Seiten

Test-driven development (TDD) is a proven way to find software bugs early. Writing tests before your code improves the structure and maintainability of your app.
Test-Driven iOS Development with Swift will help you understand the process of TDD and how it impacts your applications written in Swift. Through practical, real-world examples, you'll start seeing how to implement TDD in context. We will begin with an overview of your TDD workflow and then deep-dive into unit testing concepts and code cycles. We will showcase the workings of functional tests, which will help you improve the user interface. Finally, you will learn about automating deployments and continuous integration to run an environment.

Autoren/Hrsg.

Hauser, Dominik

Fachgebiete

• Mathematik | Informatik EDV | Informatik EDV & Informatik Allgemein

Leseproben

Chapter 1. Your First Unit Tests

When the iPhone platform was first introduced, applications were small and focused on one feature. It was easy to make money with an app that only did one thing (for example, a flash light app that only showed a white screen). The code for these apps only had a few hundred lines and could easily be tested by tapping the screen for a few minutes.

Since then, the App Store has changed a lot. Even now, there are small apps with a clear focus in the App Store, but it's much harder to make money from them. A common app is complicated and feature-rich but still needs to be easy to use. There are companies with several developers per platform working on one app all the time. These apps sometimes have a feature set, which is normally found in desktop applications. It is very difficult and time consuming to test all the features on such apps by hand.

One reason for this is that manual testing needs to be done through a user interface, and it takes time to load the app to be tested. In addition to this, human beings are very slow as compared to the capabilities of computers. Most often, you'll notice that a computer waits for the next input of the user. If we could let a computer insert values, testing could be drastically accelerated. Additionally, the computer could test the features of the app without loading the user interface; thus, the complete app could be tested within seconds. This is exactly what unit tests are all about.

Writing unit tests is hard at first because it is a new concept. This chapter is aimed at helping you get started with unit tests and how they are used in Xcode. We will also discuss Test-Driven Development (TDD), which forces us to write the tests before the implementation code. We will see how TDD is implemented in Xcode, and we will discuss its advantages and disadvantages.

We will cover the following topics in this chapter:

• Building your first automatic unit test
• Understanding TDD
• TDD in Xcode
• Advantages of TDD
• Disadvantages of TDD

Building your first automatic unit test

If you have done some iOS development (or application development in general) before, the following example might seem familiar to you.

You are planning to build an app. You start collecting features, drawing some sketches, or your project manager hands the requirements to you. At some point, you start coding. After you have set up the project, you start implementing the required features of the app.

Let's say the app is an input form, and the values the user puts in have to be validated before the data can be sent to the server. The validation checks, for example, whether the e-mail address looks like it's supposed to and the phone number has a valid format. You implement the form and check whether everything works. But before you can test, you need to write code that presents the form on the screen. Then, you build and run your app in the iOS simulator. The form is somewhere deep in the view hierarchy. So, you navigate to this view and put the values into the form. It doesn't work. Next, you go back to the code and try to fix the problem. Sometimes, this also means that you need to run the debugger, and build and run to check whether the code still has errors.

Eventually, the validation works for the test data you put in. Normally, you would need to test for all possible values to make sure that the validation not only works for your name and your data but also for all valid data. But there is this long list of requirements on your desk, and you are already running late. The navigation to the form takes three taps in the simulator, and putting in all the different values just takes too long. You are a coder after all.

If only a robot could perform this testing for you.

What are unit tests?

Automatic unit tests act like a robot for you. They execute code but without the need of navigating to the screen with the feature to test. Instead of running the app over and over again you write tests with different input data and let the computer test your code in the blink of an eye. Let us see how this works in a simple example.

Implementing a unit test example

Open Xcode and go to File | New | Project. Navigate to iOS | Application | Single View Application, and click on Next. Put in the name , select the Swift language, iPhone for Devices, and check Include Unit Tests. Uncheck Use Core Data and Include UI Tests, and click on Next. The following screenshot shows the options in Xcode:

Xcode sets up a completely ready project for development in addition to a test target for your unit tests. Open the folder in Project Navigator. Within the folder, there are two files: and . Select to open it in the editor.

What you see here is a test case. A test case is a class comprising several tests. It's good practice to have a test case for each class in the main target.

Let's go through this file step by step:

import XCTest @testable import FirstDemo

Every test case needs to import the framework. It defines the class and the test assertions that you will see later in this chapter.

The second line imports the module. All the code you write for the app will be in this module. By default, classes, structs, enums, and their methods are defined as . This means that they can be accessed within the module. But the test code lives outside of the module. To be able to write tests for your code, you need to import the module with the keyword. This keyword makes the elements of the module accessible to the test case.

Next we'll take a look at the class declaration:

class FirstDemoTests: XCTestCase {

Nothing special here. This defines a class FirstDemoTests as a subclass of XCTestCase.

The first two methods in the class are as follows:

override func setUp() { super.setUp() // Put setup code here. This method is called before the invocation of each test method in the class. } override func tearDown() { // Put teardown code here. This method is called after the invocation of each test method in the class. super.tearDown() }

The method is called before the invocation of each test method in the class. Here, you can insert code that should run before each test. You will see an example of this later in this chapter.

The opposite of is . This method is called after the invocation of each test method in the class. If you need to clean up after your tests, put the necessary code in this method.

There are two test methods in the template provided by Apple:

func testExample() { // This is an example of a functional test case. // Use XCTAssert and related functions to verify your tests produce the correct results. } func testPerformanceExample() { // This is an example of a performance test case. self.measureBlock { // Put the code you want to measure the time of here. } } }

The first method is a normal test. You will use this kind of test a lot in the course of this book.

The second method is a performance test. It is used to test methods or functions that perform time-critical computations. The code you put into is called several times, and the average duration is measured. Performance tests can be useful when implementing or improving complex algorithms and to make sure that their performance does not decline. We will not use performance tests in this book.

All the test methods that you write have to have the prefix; otherwise, the test case can't find and run them. This behavior allows easy disabling of tests: just remove the prefix of the method name. Later, you will take a look at other possibilities to disable some tests without renaming or removing them.

Now, let's implement our first test. Let's assume that you have a method that counts the vowels of a string. A possible implementation could look like this:

func numberOfVowelsInString(string: String) -> Int { let vowels: [Character] = ["a", "e", "i", "o", "u", "A", "E", "I", "O", "U"] var numberOfVowels = 0 for character in string.characters { if vowels.contains(character) { ++numberOfVowels } } ...

Über Autor(innen)

Hauser Dr. Dominik :

Dr. Dominik Hauser is an iOS developer working for a small company in western Germany. In over 11 years as an iOS developer, he has worked on many different apps, both large and small. In his spare time, Dominik builds small (often silly) apps and explores how he can become a better iOS developer. He talks at conferences, writes books, and is active in the iOS community in general. His most successful open source component (in terms of stars) is a pull-to-refresh control for a table view that consists of an actual SpriteKit game. Before Dominik became an iOS developer, he was a physicist, researching the most powerful photon sources within our galaxy.