Test-Driven Development — Part 1

Photo by Ren Ran on Unsplash

What is TDD

Test-Driven Development is a software development process to manage your software architecture whether something is missing or didn’t meet the requirement. There are three steps to do TDD:

1. Write a failing test (RED),
2. Write some codes to make it successful (GREEN), and
3. Refactor codes to improve the structures (YELLOW).

Why do we need TDD

There are three reasons why TDD is going to help us in software development:

1. By doing TDD, it’ll give us easy-to-change codes. Our unit tests cover cases we may miss.
2. It helps us do UI testing without getting into some screens one by one.
3. TDD helps us direct our software architecture by showing what’s missing and what kind of requirements we need.

What should we Test?

Before we jump into it, remember to try not to reach a hundred percent unit test coverage. It is because a hundred percent unit test coverage isn’t the best practice for real-world software.

There are things to test and vice versa:

1. Test the application domain to test how is the business works in this software. The application domain has the most complicated business rules, and we need to check them with TDD.
2. We don’t need to test a generated code, which means it’s not coming from what we’ve written. It is because the implementation will likely change.
3. We also don’t need to test a test compiler result.
4. Third-party libraries aren’t needed because we didn’t have to test if it’s working.
5. Testing the application UI with automation prevents us go to the tested screen manually.

Lastly, we don’t want to test whether some properties successfully save the value properly or anything from the Swift language. All we have to check is the application domain and the UI.

When should we use TDD?

TDD is the best start for greenfield development (early) to explore what kind of business rules we want to make and brownfield development (legacy) to learn about the existed software’s business rules. Mainly, TDD is to test and know about the application domain.

TDD only fits in software with a long working period, meaning the hackathon software with a length of day or two days doesn’t work well using TDD. In a hackathon, you want to finish the software quickly and may have a little bit of bug instead of longevity.

Misconceptions of TDD

Testing isn’t the QA’s job because the developer had access to their code, while QA doesn’t. QA uses different tools with the developer when they test software.

Based on the steps of TDD, it may sound tedious and take more time to finish a unit test. The benefit of TDD doesn’t show off for a day or week, but it’s for half a year or more than a year.

When we implement TDD without consciousness, we’ve created a safety net when we occur a new feature or update legacy code. It gives us confidence and easy-to-change code.

As a reminder, some clients don’t want the developer to implement TDD because it takes more time to finish the software. To outwit this situation, we need to add some extra hours from the estimated completion of work.

Bad Unit Testing

Poor unit testing is a unit test where we try to see whether the programming language can create something successfully or not. This decision will cause the software to have hundreds of poor unit tests.

For example, we test if the Swift programming language can initialize a class or struct. Or we check if the programming language can change the variable’s value.

These bad examples do not correlate with testing the application domain or any instructions you’ve created to perform tasks. Rather than that, we should check our logic contains an input and an output with unit testing.

Good Unit Testing

Good unit testing has a characteristic as follows:

1. It should be independent without depending on the other unit tests.
2. A unit test must run automatically every time we run it.
3. The result of the unit test should be consistent and repeatable. It doesn’t have to depend on how many times it’s run.
4. A unit test should be readable and easy to understand so other developers know the purpose of each unit test.

Summary

TDD is a software development process to test the software application domain with complicated business logic. To implement it, we start by creating a failing test (RED), write codes to make it successful (GREEN), and finally refactor codes to improve the structures (YELLOW).

Acknowledgment

Arifin Firdaus for sharing his knowledge and guiding about Testing in Swift.

Mohammad Azam for creating an Udemy course about Testing iOS Apps.

Further Learning

Mohammad Azam constructed a paid course about Testing iOS Apps, discussing Unit Testing, Test-Driven Development & Behavior-Driven Development implementation in Swift.

Updates

9th December 2021: I edited the definition of the bad example of the unit test. Instead of focusing on the application domain only, we also need to focus on any instructions we created to do some tasks. Thank you for pointing that out, Arifin Firdaus.