Book Image

Test-Driven iOS Development with Swift 4 - Third Edition

By : Dr. Dominik Hauser
Book Image

Test-Driven iOS Development with Swift 4 - Third Edition

By: Dr. Dominik Hauser

Overview of this book

Test-driven development (TDD) is a proven way to find software bugs early. Writing tests before you code improves the structure and maintainability of your apps. Using TDD, in combination with Swift 4's improved syntax, means there is no longer any excuse for writing bad code. This book will help you understand the process of TDD and how to apply it to your apps written in Swift. Through practical, real-world examples, you’ll learn how to implement TDD in context. You will begin with an overview of the TDD workflow and then delve into unit-testing concepts and code cycles. You will also plan and structure your test-driven iOS app, and write tests to drive the development of view controllers and helper classes. Next, you’ll learn how to write tests for network code and explore how the test-driven approach—in combination with stubs—helps you write network code even before the backend component is finished. Finally, the book will guide you through the next steps to becoming a testing expert by discussing integration tests, Behavior Driven Development (BDD), open source testing frameworks, and UI Tests (introduced in Xcode 9).
Table of Contents (9 chapters)

Enabling code coverage

Measuring the code coverage of our tests gives us a feeling of completeness about our test suite. While following the TDD workflow, as we don't write any code without a failing test, the code coverage of our project should be very high. We don't expect it to be 100%, meaning that all the code paths are executed in the tests because the static analyzer forces us to write code that we don't expect to be executed. For example, in the code we wrote, we often used guard to make sure that the value we wanted to access was not nil. We could have written tests for a case where the value was nil. But in my opinion, in most cases these tests give no additional value.

Nevertheless, we will examine the parts of the project without code coverage and discuss whether we need to add tests to cover them.

...