Test Driven Development (TDD), Step by Step: Part 1

Introduction

So at first let’s ask ourselves what is Test Driven Development(TDD)?

“TDD is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and then refractor the code to pass the test”.

TDD is upside-down approach for non-TDD developers. What’s our natural approach to development is? We write code to implement a functionality in mind. Once we finish coding, we test then modify if error is found and test again. This cycle continues. This traditional non-TDD approach is shown below:

Image 1: Traditional Approach to Software Development.

 

On the other hand in TDD approach you write test first rather than production code. So in reality with TDD even if you don’t have a class OrderProcessSystem (considering you are working on a order processing system) you are writing test for making sure Order Processing System is working fine just taking for granted that the class OrderProcessingSystem exists. It might sound bizarre. But its the main point in TDD .You want your test to fail at this point. Then go create classes, add functionalities and make sure the test passes. The overall approach is “You write the tests first, watch them fail, and then start producing the code that will get them to pass”. I’ll show you this in details later in this series of post. The TDD approach is shown below in the following figure:

Image 2: TDD approach to software development.

Why TDD? What’s the problem with traditional approach?

Now you may ask hey man I am not using TDD but my development is going well. I‘m delivering product in time with quality and bla bla bla. To answer your question let me remind you first “No process in this world is the best in all cases”. Every process has its merits and demerits. Even if nowadays waterfall model is appropriate for some kind of systems. So my focus is not TDD is best over non-TDD approach. Rather TDD offers some sort of benefits that we can leverage:

1. Automated testing: Nowadays as system is getting bigger and complex people are moving to automated testing. Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system. Whereas human may left a test out mistakenly during testing process.

2. Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test the all systems that may be affected due to the modification which may be time-consuming. This may also left hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified the whole set of tests in the system is run to make sure existing tests are passed. This make sure that existing functionality is not broken.

3. Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to be failed. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).

4. manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increase the time to deliver the product from the build time. With TDD a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.

5. Alternative Documentation: Unit tests are kind of documentation to system. Each unit tests tell about a individual requirement to the module or system. For example the following test ensure that only a logged in user with proper balance can buy an item when the item exist in stock. This test reflects an user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance()
{
    LoginToTheSystem();
    SelectAnItemToBuy();
    MakeSureItemExsitsInStock();
    MakeSureUserHasBalanceToBuy();
    RunTheTransaction();

}

6. Better way to fix bugs: In TDD approach when QA finds a bug, developer first write a test that generate the bug (that is the test will fail due to this bug). Then developer modify code to make sure that the test is passed (i.e., the bug is fixed). This approach make sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.

7. Repetition of the same bug reduced: The way bug are fixed in TTD is described in point 6. With TDD once a bug is found its put under test. So every time you run the whole tests in the system the tests associated with the bug are run and make sure the bugs are not generated again.

Are you convinced with TDD?

May be reading the above section you have convinced that TDD is the best as it offers so may benefits. From my personal experience before introducing any new approach you need to know:

1) What’s skills, the new approach expect developers to have?

2) What’s the restriction/demerits of the approach?

3) Will this approach fit with your system or environment? How can you fit TDD in your team?

Lets answers these questions.

Skill set requirements: With TDD developer writes test first rather than code. Many developers find it difficult to follow this approach (and most of the time resist not to follow TDD) as they are used to write code first. Most of the time non-TDD developers don’t want to follow this “test first then write code” as this is upside-down way of developing to them. Also in TDD the whole dependency is on Test case. TDD considers that test is the right thing and we need to make sure the test passes. But what if the test itself is not correct or enough tests are not written to cover all aspect of the system. If your test doesn’t cover all aspects of the system then may be you are missing some parts of the system to test. This is the case with manual testing and we are using automated testing to make sure whole part of the system comes under test. So writing good test cases is important for making successful TDD system. But if you don’t start and practice writing tests you don’t know how to write good tests.

Restriction of TDD: TDD requires having good skills on writing test cases which cover all aspects of the system. But writing good test cases requires to introduce TDD and practice more and more to be expert in TDD. So initially after introducing TDD you may not get the full benefits of TDD until you have a good number of people in your team having good skill in writing TDD. Also TDD can’t cover all aspects of the system. For example you can’t test UI, multithreading etc. So even including TDD you need to have manual tester. Sometimes you need to maintain tests as well as code to make sure that tests reflect the system requirements. This is an extra overhead for TDD.

How to Introduce TDD in your team: Once you are convinced with TDD you’ll try to Introduce TDD in your team. But you need to be careful and need to consider the following aspects before introducing TDD.

• sometimes some good initiative fails due to the way initiative is taken or introduced. For example you are overwhelmed with TDD and then decided to force all members in your team to follow TDD. From my point of view this will introduce a catastrophic productivity loss of the whole team. First of all you need to consider that your team members need to be expert in TDD to get full benefit of TDD. So introduce TDD in a small scale. Ask 2/3 developer to follow TDD. Once they get used to TDD ask few others to join with them. This way after few months you will find that your whole team is following TDD.
• Sometimes you’ll find few members of your team are not interested in TDD.Don’t force them to follow TDD. Rather use TDD with others who are interested.If you can prove TDD is better then once the guy who resisted to follow TDD will come and follow TDD.
• Select proper time to introduce TDD in your team. For example you have production release next month and you have bunch of works to do. Introducing TDD at this stage will slow the productivity of the team down. So select time to introduce time when you have less work pressure and team is in relaxing mode to learn and practice new approach.

Misconceptions about TDD

Some people argue that TDD takes more time than non-TDD approach. This may be true when you are introduced TDD in your team and your team members don’t have expertise in TDD (i.e., how to write test cases). Remember in the long run your team members will be expert in TDD and you’ll get the full benefits of TDD.

May be the above argument will not satisfy you as you will argue that writing TDD will take time which we could save if we wouldn’t write test case. This is true that writing tests takes extra time but it also saves time from other ends. Without TDD you need to depend fully on manual testing. In non-TDD approach you use to run the code, debug to test or find bugs. So with non-TDD approach you spend most time on manual testing. Also with non-TDD approach reasonable time is spent with QA personal to test the system. But with TDD approach you spend more time to write test cases but less time to run-debug and also less time with manual testing. So My argument is that with TDD your testing time is finally reduced as developers don’t need to depend heavily on manual testing and as testing with QA personal is shortened.

codeproject