What is Test Driven Development(TDD)?

Test-driven development(TDD) is a methodology in software development that prioritises testing before production. This approach involves running tests and then using their

outcome to determine what code to write. The process begins with writing test cases for

every unit of an application and then writing code to pass that test specifically. It is also

known as Test First Development.

A unit is the smallest testable functional part of an application, and by running unit testing

before writing code, TDD enables developers to avoid bugs during the coding process. The

concept of TDD is to write and correct the failed tests before production(writing code).

TDD consists of short repetitive development cycles that base testing on software

requirements rather than just code implementation. It is an iterative method of development

that comprises building, testing and design(refactoring) to enhance code accuracy and

product functionality.

This article aims to discuss TDD in simple terms. It is outlined as follows:

●What is TDD?

●What is Testing?

●Performing TDD Testing

●Types of TDD

●TDD in Agile development

●Tools for TDD

●Conclusion

What is Test Driven Development(TDD)?

Test-driven development (TDD) is an Agile software development methodology focusing on testing before writing code. Test-driven development aims to ensure that the codebase is error-free and that it adheres to the project's requirements. By writing tests first, developers can quickly identify issues with the code and make necessary changes to ensure that the code works as expected.

The process of test-driven development begins with writing an automated unit test for a specific feature of the code. The test should evaluate the feature for any errors and should fail if the feature does not meet the requirements. Once this test has been written, the developer can write the feature's production code. When the code is written, it can be tested against the unit test to ensure it works as expected.

TDD encourages developers to think about the design of the code before writing it. By writing tests first, developers can consider the design of the code and ensure that it meets the project's requirements. This helps to prevent any potential issues that could arise from having poorly designed code.

Another benefit of test-driven development is that it helps to ensure that the codebase remains stable. By writing tests for each feature, any changes made to the code can be quickly evaluated against the tests to ensure that it does not break any existing code. This helps to ensure that the codebase remains stable and that any changes to the code do not introduce any new errors.

What is Testing?

Testing is the process of ensuring that a program or application is functional for the specified

purpose for which it was developed. It is done to determine if your code does what you have

written it to do. Testing is a critical component of any software development lifecycle, as it

saves time, cost and inconveniences of deploying flawed products. It can generally be

approached either manually or through automation.

Manual Testing

Manual testing is physically navigating your application or code to test functionality and

uncover bugs or vulnerabilities.

Automated Testing

Automated testing, on the other hand, uses written code to scan other code for functionality

and shortcomings. As a result, automated testing is typically broader and faster.

Using both methods in tandem is the recommended procedure for thorough testing. This

way, you can locate and uncover both known and unknown vulnerabilities.

Performing TDD Testing

Test-driven development focuses on specifying what function your program should perform,

creating a test, and then writing just enough code to pass that test. Basically, the TDD cycle

is defined by the following steps:

Write a unit test specifying the program requirements

Run a failing test

Write code to pass the test

Refactor the code until it meets the satisfaction

Repeat unit tests over time

The three major phases of TDD testing are Red, Green and Refactor.

Create unit Test(Red)

The initial step is to create a test based on the specific functions of the product you plan to

make and run it. This test should fail because you have not applied any code. The key

motivation at the red stages is “what” to develop.

Create the Code(Green)

The next step involves writing code to pass that test in the simplest possible way. The aim is

to find the most straightforward solution quickly by writing just enough code to pass the test.

Once the test is passed, you can move on to optimisation in the next stage. Here, the

question is “how” to develop.

Refactor

The goal at this stage is not to fix code but to improve and optimise it to suit the specified

requirements better and deliver the best performance. Developers should take care during

refactoring to avoid altering the program's external behaviour. The important questions to

ask here go along the lines of “what can I do more efficiently?”

Can my test suite be more expressive? How?

Can I make my code more descriptive? How?

Can my test suite provide more reliable feedback? How?

Can I reduce duplication in my code? How?

Principles of TDD

Write test first

More traditional software development methodology involves writing code and

testing it later. On the other hand, Test Driven Development flips the script by requiring

developers to write a test first, run the test and then improve on the code.

Write enough code to pass the test

The aim is to write a quick first test(first development) and make it pass with the simplest

change to the production code possible.

Subsequent code updates and testing

Depending on the result of the test, the outcome is either 'red' or 'green'. A test that has

passed is represented as green as 'green') you can refactor from a green test to another

green test. Following a refactor, if all tests are green, you proceed to your next failing

test.

Acceptance testing to prevent new software bugs – If you are a developer, the main aim

is to write and run continuous tests to uncover any bugs and see if any changes or

enhancements made resulted in faults or bugs.

Example

Here we depict an example of TDD using a non-technical subject such as building a shed:

1. I expect the shed to be two metres high.

2. The test fails because I have built no shed.

3. I erect a pillar and put a thatch roof on it.

4. The test passes.

2. The test fails because you only use one pillar and a handful of thatch.

3. You add three more pillars and expand your roofing.

4. The test passes.

2∙ The test fails because when the pillars are lightweight and unprotected.

3∙ You build a wall around the pillars.

4∙ The test passes.

This would continue on and on until the shed was complete.

Types of TDD

There are two major types of Test-driven development models:

Acceptance TDD (ATDD): An acceptance test is a formal description of the expected

behaviour of a software product as written from an end user's point of view. Acceptance TDD

involves testing to meet the requirement of the end user as specified in the acceptance test

before developing code. It is almost identical to BDD (Behaviour-driven development), with

the major difference being that ATDD prioritises the accuracy of specified requirements,

while BDD emphasises overall user behaviour.

Developer TDD (DTDD): This is the basic TDD testing where a developer creates a unit test

before writing production code to pass that test. The unit test focuses on all the smallest

testable functionalities of the system.

TDD in Agile development

Agile development is an ever-evolving and constantly improving methodology that thrives on

continuous feedback. Iteration and incremental development characterise the Agile SDLC,

and this is why TDD is tailor-made for Agile. The by-product of its test-first nature is that

feedback is received and implemented early and continuously through every phase of the

project. By translating customer feedback into bug fixes and adding new features,

the system regularly adapts to make everything work as intended.

Relationship with Agile Model Driven Development (AMDD)

Agile model-driven development is an approach to software development where extensive

models are created before writing source code. AMDD plays an essential role in scaling

agile software development. It is also useful as scaling TDD because although it excels at

detailed specification and validation, TDD could be less functional for the overall design.

Since the detailed specification is only a part of the entire picture, we sometimes need to

look past TDD to utilise AMDD. Below is a detailed process of scaling TDD using AMDD.

Envisioning

Typically done on the first week of an initiative, this is the process of picturing tests,

identifying your system's scope, and developing an architecture for it. The goal is to explore

the requirements and define an overall strategy. This involves high-level requirements

modelling and high-level architecture modelling.

Iteration modelling

This is where the team defines the work to be done in every iteration. Work items will be

added incrementally in every iteration. Items with higher priority are taken into consideration,

and the team decides how to implement the specified requirements.

Model storming

This involves a team deliberating issues on a whiteboard or paper. This session will take an

estimated 5 to 10 minutes, during which team members gather together to share the

whiteboard.

They analyse the issues until they don't find the major problems. When a team member

identifies the issue that they want to resolve, then they will seek help from other teammates.

The group members then assess the issue and then carry on.

Executable specificationusing Test-Driven Development (TDD)

An executable specification is an automated test that shows and verifies how the application

delivers a specific requirement. The automated tests are part of the production process and

run whenever a change is made to the application.

During development, it is normal for the team to model storm for several minutes before

coding and refactoring, for as long as several days at a time to implement the model. This is

where the team members will spend most of their time.

Agile teams do most of their detailed modelling through executable specifications, often

customer tests or development tests. This works because model storming assists thinking

through larger, cross-entity issues, while TDD teaches you to think through focused issues

pertinent to a single entity at a time. With refactoring, you can make little adaptations to your

design while your program maintains high quality.

Reviews This encompasses model reviews and even code inspections. It is optional and can be done

for either single iterations or the entire project. It is an excellent source of feedback.

Difference between TDD and AMDD :

	TDD	ADD
	TDD refers to Test Driven Development.	AMDD refers to Agile Model Driven Development.
	TDD develops the test cases before the software is fully developed and makes necessary updates based on test results.	AMDD is an Agile version of MDA (Model Driven Architecture) or Model Driven Development (MDD), where extensive models are designed before source code is written.
	This technique focuses more on the implementation of a feature.	This technique focuses more on the implementation of functionality.
	It shortens the programming feedback loop.	It shortens the modelling feedback loop.
	It does not address the agile scaling issues.	It addresses the Agile scaling issues.
	It promotes the development of high- quality code.	It promotes high-quality communication with stakeholders and developers.
	It provides detailed specifications.	It is better for thinking through bigger issues.
	Participants are programmers.	Participants are stakeholders, and data professionals, business analysts.
	It is not visually oriented.	It is visually oriented.
	TDD has a limited scope than AMDD.	AMDD has a larger scope than TDD.

Advantages of TDD

The following are the main advantages of Test Driven Development in Software Engineering:

Identify bugs early

A test-first approach uncovers bugs very early in the development cycle. It also gives more

precise insight into understanding the requirements and how to use codes to meet them.

TDD ensures that all production codes pass tests based on user requirements.

Enhance overall design

TDD address one small feature at a time. This means every unit is independently tested,

resulting in more efficiently written code than broader focused testing methods.

Detailed documentation

These tests can act as documentation. The TDD process details how code works and the

changes in the project, resulting in well-structured documentation and a clear roadmap of the

whole project.

Better code quality and flexibility

In TDD, developers visualise what specific problems they aim to solve before testing and

writing code for it. This results in the delivery of high-quality products with fewer flaws and

cleaner code (source).

Lower costs

By reducing flaws, minimising bugs, making code maintenance more manageable, and

improving general efficiency, Test-driven development can significantly decrease the

project’s cost. A joint study by Microsoft and IBM showed that four development teams

who adopted TDD recorded a 40-90% reduction in their defect density.

Disadvantages of TDD

●Slow development process

Because developers must first write tests must and run them for failure, the TDD

method can stall the development cycle longer than necessary. The preoccupation of

developers with building test cases allows them less time to work on code. In a

project with limited timelines, this can be a big negative.

●Difficult to learn and operate

Test-driven development requires a higher modelling skillset than most developers

have.

● Difficult to maintain and support

The need to adapt to changes in user requests can be a bother, as code will be

adapted or created to run new tests for each request. Also, the bigger a project is,

the more difficult it is to maintain the multiple unit tests.

Frameworks for Test-Driven Development

Many frameworks support test-driven development. Some popular ones among them are:

csUnit: An open-source tool for .Net projects unit testing

DocTest: A unit testing framework for Python testing framework

JUnit: A unit testing framework for Java.

NUnit: A .Net projects TDD testing framework

PHPUnit: A PHP projects testing framework

PyUnit: A Python unit testing framework

TestNG: A Java testing framework

RSpec: A framework for Ruby projects.

Importance of failing tests

While it may seem like wasting time, failed tests are as essential as passed ones. This is

because it points out that all code used is necessary and functional. Failing tests help you better identify your product goal, its challenges, and how to surpass them.

When to use TDD

The Test-driven development model is best applied in environments where:

●You are trying to define layers within your application

●You have detailed specifications of the design, business decisions and budget and

time constraints

●You have a small-scale project

●You are working in a team

Conclusion

Overall, test-driven development is an important tool for software development. By writing tests first, developers are able to ensure that the code works as expected and that any changes to the code do not introduce any new errors. This helps to ensure that the codebase remains stable and that the project meets its requirements.

TDD improves feedback and correctness and gives us a framework to clearly visualise our

code at an early stage.