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)

The disadvantages of TDD

Just like everything else in the world, TDD has some disadvantages. The main ones are here:

  • No silver bullet: Tests help to find bugs, but they can't find bugs that you introduce in the test code and in implementation code. If you haven't understood the problem you need to solve, writing tests most probably won't help.
  • It seems slower at the beginning: If you start TDD, you will get the feeling that it takes longer to make easy implementations. You need to think about the interfaces, write the test code, and run the tests before you can finally start writing the code.
  • All the members of a team need to do it: As TDD influences the design of code, it is recommended that either all the members of a team use TDD or no one at all. In addition to this, it's sometimes difficult to justify TDD to the management because they often have the feeling that the implementation of new features takes longer if developers write code that won't end up in the product half of the time. It helps if the whole team agrees on the importance of unit tests.
  • Tests need to be maintained when requirements change: Probably, the strongest argument against TDD is that the tests have to be maintained as the code has to. Whenever requirements change, you need to change the code and tests. But you are working with TDD. This means that you need to change the tests first, and then make the tests pass. So, in reality, tests help you to understand the new requirements and implement the code without breaking other features.