Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Test-Driven iOS Development with Swift 4

You're reading from   Test-Driven iOS Development with Swift 4 Write Swift code that is maintainable, flexible, and easily extensible

Arrow left icon
Product type Paperback
Published in Oct 2017
Publisher Packt
ISBN-13 9781788475709
Length 222 pages
Edition 3rd Edition
Languages
Tools
Arrow right icon
Author (1):
Arrow left icon
Dr. Dominik Hauser Dr. Dominik Hauser
Author Profile Icon Dr. Dominik Hauser
Dr. Dominik Hauser
Arrow right icon
View More author details
Toc

Understanding TDD

Now that we have seen what unit tests are and how they can help in development, we are going to learn about TDD.

In 1996, Kent Beck introduced a new software development methodology called Extreme Programming. The word Extreme indicates that the concepts behind Extreme Programming are totally different from the concepts used in software development back then. For many people, these concepts sound extreme even today.

The methodology is based on 12 rules or practices. One of the rules states that developers have to write unit tests and all parts of the software have to be thoroughly tested. All tests have to pass before the software (or a new feature) can be released to customers. The tests should be written before the production code that they test.

This so-called test-first programming led to TDD. As the name suggests, in TDD, tests drive the development. This means that the developer writes code only because there is a test that fails. The tests dictate whether the code has to be written, and they also provide a measure when a feature is "done"--it is done when all tests for this feature pass.

Robert C. Martin (known as Uncle Bob) has come up with three simple rules for TDD:

  • You are not allowed to write any production code unless it is to pass a failing unit test
  • You are not allowed to write any more of a unit test that is sufficient to fail, and compilation failures are failures
  • You are not allowed to write any more production code that is sufficient to pass the one failing unit test

These rules sound kind of silly because when you start with a feature that uses a new class or method that is not declared yet, the test will fail immediately, and you have to add some code just to be able to finish writing the test. But by following these rules, you will only write code that is actually needed to implement the features. And you will only write test code that is needed as well. All the code you write will either end up being part of the final product or it will be a part of your test suite.

Because of the focus on just one feature at a time, you will have a working piece of software almost all the time. So, when your boss enters your office and asks you for a demonstration of the current status of the project, you are only a few minutes away from a presentable (that is, compiling), and a thoroughly tested piece of software.

The TDD workflow - red, green, and refactor

The normal workflow of TDD comprises three steps--the red, green, and refactor steps, respectively. The following sections describe these steps in detail.

Red

You start by writing a failing test. It needs to test a required feature of the software product that is not already implemented or an edge case that you want to make sure is covered. The name red comes from the way most IDEs indicate a failing test. Xcode uses a red diamond with a white x on it.

It is very important that the test you write in this step initially fails. Otherwise, you can't ensure that the test works and really tests the feature that you want to implement. It could be that you have written a test that always passes and is, therefore, useless. Or, it is possible that the feature is already implemented. Either way, you gain insight into your code.

Green

In the green step, you write the simplest code that makes the test pass. It doesn't matter whether the code you write is good and clean. The code can also be silly and even wrong. It is enough when all the tests pass. The name green refers to how most IDEs indicate a passing test. Xcode uses a green diamond with a white check mark.

It is very important that you try to write the simplest code that makes the tests pass. By doing so, you only write code that you actually need and that is the simplest implementation possible. When I say simple, I mean that it should be easy to read, understand, and change. The code should always be easy to understand.

Often the simplest implementation will not be enough for the feature you try to implement, but still enough to make all the tests pass. This just means that you need another failing test to further drive the development of that feature.

Refactor

During the green step, you write just enough code to make all the tests pass again. As I just mentioned, it doesn't matter what the code looks like in the green step. In the refactor step, you should improve the code. You remove duplication, extract common values, and so on. Do what is needed to make the code as good as possible. The tests help you to not break already implemented features while refactoring.

Don't skip this step. Always try to think how you can improve the code after you have implemented a feature. Doing so helps to keep the code clean and maintainable. This ensures that it is always in good shape.

As you have written only a few lines of code since the last refactor step, the changes needed to make the code clean shouldn't take much time.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime