Test Driven Development: A reverse approach to software development

What is Test Driven Development?

Traditionally, developers write code and then test it. Test Driven Development (TDD) reverses this process: testing happens first, and then the code is written.

Developers create unit tests before developing code in an iterative process that combines coding, writing unit tests and refactoring.

TDD works by creating a test case for each feature of a product. When the test fails, the developers write or modify the code. This approach prevents duplication of test scripts and allows developers and testers to create optimized and resilient code.

Why use TDD?

TDD fosters the creation of optimized code, can streamline software development, enhance productivity, and lead to a flexible codebase that is easy to maintain.

A TDD workflow helps our developers to analyze and understand a client's requirements and request clarity where they are not adequately defined.

Adding and testing new functionalities becomes much easier in the later stages of development. Additionally, because TDD focuses on creating tests for each functionality right from the start, test coverage under TDD is much higher when compared to the conventional development models.

How does TDD work?

TDD works in small increments where:

1. The test is written first
2. The test is executed – which will fail because the feature doesn't yet exist in the program
3. The code is written (or refactored) to make the test case pass
4. The test is executed again
   1. If the test passes, move on to the next test
   2. If the test fails, re-write or modify the code to make the test pass

How to get started with TDD

Understand the testing requirements

Before writing any unit tests, the first step is to review and test the requirements. The aim is to consider all the possibilities and understand what needs testing before designing the tests.

For example, a single requirement could be one of many examples that could occur. Or there could be instances where it could be wrong.

This step will help improve the design and code quality from the start; rather than fixing bugs in a reactive approach.

Review unit test scenarios before code writing

Before writing the test scenarios, ensure you review the unit testing strategy. This will help you assign the risk associated with the module being tested and will save time on rewriting code later on.

Create a risk assessment matrix to prioritize testing

Now that you know what you want to test and how intensively, the next step is to consider the risks and their priorities.

A risk is the probability of an occurrence of an uncertain event which could impact the business, cost or the quality or technical targets of the project. The risk could be a current, past or future event.

Calculating the risk rating helps us decide how many unit tests to write. The higher the priority, the higher the test coverage will be.

A risk assessment matrix provides the project team with a handy overview of the risks and the priority in which they should address them. To work out the risk rating, we need to look at probability and severity.

Probability is the chance of an uncertain event occurring, which we measure as a percentage:

• Frequent (91 - 100%)
• Probable (61 - 90%)
• Occasional (41 - 60%)
• Remote (11 - 40%)
• Improbable (0 -10%)
• Eliminate (0%)

Severity is the degree of impact an uncertain event causes and are classified as:

• Catastrophic — Severe Consequences that make the project unproductive or lead to project shut down. Top priority during risk management
• Critical — Large consequences: Project is severely threatened
• Marginal — Short-term damage which is still reversible through repair
• Negligible — Little or minimal damage or loss. Can be monitored and managed by routine procedures

Once we know the probability and severity, we can map these into four categories in the risk assessment matrix: High, Serious, Medium and Low. Risks falling into High or Serious must be dealt with immediately.

Applying TDD: A case study

Here at Deltatre, we find a TDD approach works well for many of our projects, including when we worked with ITV to create the BritBox OTT platform.

What is BritBox?

BritBox UK is a niche streaming video on demand (SVOD) service by BBC and ITV. It aims to address a specific content category and bring the very best in past, present, and future British programming and award-winning content to viewers all in one place.

At launch, we worked with BritBox UK to offer access to the BritBox app across different platforms, including Responsive Web, Android, iOS, Samsung and Apple TV. Later we added YouView, Fire TV, Freeview Play, Roku and Chromecast, with more planned for the future.

Requirements

The brief from ITV was:

1. To create a global, entertainment dedicated OTT home for UK TV content
2. For the user experience to be on par with streaming giants such as Netflix, Amazon Prime and Apple TV
3. To maximize audience reach opportunities by focusing on platform accessibility
4. A quick, straightforward, seamless time to market and launch

From the start of the project, we needed to bring the separate platform teams together to work as a whole team. Adding TDD created a good point to start conversations and introduce standards.

The results

TDD worked well for the BritBox UK project and helped the development teams to work together. However, we didn’t use just TDD alone; we also asked the developers to own and test their code thoroughly. By working in this way, we were able to reduce bugs and reopens of the tickets.