Understanding TDD - Part 1 - “What is TDD?”

Understanding TDD

This post is written with the intent to help understand the concepts around TDD and help in the adaptation of the TDD approach in the development process. The intended targets are developers, Team leads, and managers. The idea behind creating this was to explain the background of TDD. This first part covers the origins of TDD and the basic principles that define development with TDD.

-------------------------------------------------------------------------------------------------------------------------------------------------------------

What is TDD?

Test-driven Development abbreviated to TDD,  is an Approach to problem-solving or application/software development when unit tests are written prior to writing code.  Before jumping in headfirst into Test-driven Development (TDD) let’s look back at the background of how TDD came to be.

History of TDD

"Generally, the modern “rediscovery” of TDD is attributed to Kent Beck, who is also known as the creator of Extreme Programming. Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software and higher quality of life for the development team." The general characteristics of Extreme Programming (XP) described in extreme programming are. 

1. Extreme Programming (XP) was created in response to problem domains whose requirements change.
2. XP is set up for small groups of programmers. 
3. The XP team includes not only the developers but the managers and customers as well, all working together elbow to elbow.
4. Another requirement is testability. You must be able to create automated unit and functional tests.
5. The last thing on the list is productivity. 

XP gave a broad framework on which TDD would become a Development practice used to drive quality code.

The Agile Mindset of development teams.

The Agile Manifesto is tantamount to a “declaration of independence” for Agile Software development. Many offshoots the agile system are extreme programming, scrum, pair programming, refactoring, and many more. The agile manifesto is also important in the development of TDD as many of the principles of the manifesto are key drivers in TDD. Some of the direct correlations of the principles are:

• “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”. As we write Tests for every block of code any faults to any specific part of the software will be flagged. 
• “Working software is the primary measure of progress.”
• “Simplicity--the art of maximizing the amount of work not done--is essential.”. To facilitate testable blocks the code is designed to be simple.

Let's Look at The Traditional Process

Traditional development process.

The traditional development standard follows a broken process that is meant to fail over the long run. The major flaw in the traditional process is when a new change is brought in, it can be in the form of a bug-fix or a feature enhancement there is bound to be a change in the pre-existing code. Factoring in the human element of the developer, gaps in the unit testing can arise due to human error. This brings us to the infamous statement: “Fixing one bug causes (N) new bugs”. This constant back and forth between the different members of the team cause the team to question their own competence and approaches to problem-solving, negatively affecting the team's morale.

The TDD Process

The General flow chart of the TDD process is:

TDD Process

Derek Barber, in his blog, defines the TDD process/cycle to have 4 main steps:

1. Write a test
2. Make it run.
3. Change the code to make it right i.e. Refactor.
4. Repeat process.

In TDD, a test is added and tested with the code produced. The code is reworked until all the tests are passed. Additional features are added one by one in an incremental process. Additional tests are added to the testbed as and when needed. In the traditional way, all the implementation is completed and then test cases are designed. The code is run through all the tests and is reworked until desired functionality is achieved. 

Some clarifications about TDD:

1. TDD is neither about "Testing" nor about "Design". It is a development process. the focus is on developing good quality and clean code.
2. TDD does not mean "write some of the tests, then build a system that passes the tests.” The idea is to write tests that quantify the action the block of code is intended to do.
3. TDD does not mean "do lots of Testing." TDD is heavily reliant on good test cases (quality) and not on the number of test cases(quantity).

TDD is a process about Development. It is about writing quality unit tests that guarantee the quality of the code that is being tested. The purpose of the entire development process is to reduce the manual overhead of rechecking everything. In subsequent posts, we'll look at some of the hurdles to adopting TDD as a process.