Test-Driven Development

This is my journey about learning TDD (Test-Driven Development). I first heard about TDD at work. Our new lead was asking us to implement test in our code. It was my first step towards TDD. Then, I looked it up on the internet, and got interested in the process.

What is TDD?

TDD is a development process where your tests drive your development. It means that you should write test before code, so you have to think what you have to code and then you can write your tests. You can do that by repeating a short development cycle: The TDD Cycle. This process will help to make your code clearer, bug free and improve your productivity.

Why should I use TDD?

When your codebase has thousands of lines and you have to implement a new feature or fix a bug, TDD will help you to make sure:

• your code does what you think it does. Since you write tests before code, you have to know what your are going to code, which is the behavior you want to implement, otherwise you won’t be able to write test.
• it prevents side effects/regression. Even if you write code no being tested and you are sure of what it does, you cannot be sure that later on someone will change this code and add an error.
• all edge scenarios are handled.

It helps to design your application from your client point of view.

TDD Cycle

According to Kent Beck’s book “Test-driven Development: By Example”, the roots of TDD consists of the following 2 rules:

1. Don’t write a line of new code unless you first have a failing automated test

2. Eliminate duplication

The Two rules imply an order to the task of programming.

Red Green Refactor

The TDD cycle follows these 3 steps. They guide your TDD development and it gets you into a continuous feedback loop from each cycle so you always know what you are doing and where you are going.

Red — Write a little test that doesn’t work, and perhaps doesn’t even compile at first.

Green — Make the test work quickly, committing whatever sins necessary in the process.

Refactor — Eliminate all of the duplication created in merely getting the test to work.

This process should be 30 seconds long.

Creating your first test

From adding a new file template of type Unit Test Case Class, you get:

import XCTest
class Test: XCTestCase {
    override func 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.
    }
    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.measure {
            // Put the code you want to measure the time of here.
        }
    }
}

A test method must always start with the prefix “test”, with no parameters, so the XCTest framework knows there is an assertion to verify.

Test case structure

Screenshots from Advanced Testing and Continuous Integration by Apple

• A test case (filled grey rectangles) is a group of related test methods from a XCTestCase class. It belongs to a test suite.
• A test suite is a collection of test cases. It belongs to a test bundle.
• A test bundle is a collection of test suites.

Source

Advanced Testing and Continuous Integration - WWDC 2016 - Videos - Apple Developer