Test Driven Development - What is it?

I'll try my best to explain what it is in simple possible words.

Yes, in simplest words as the name suggests, it is "test driven development". Its writing test cases even before thinking about writing the code. If you are developer who never tried TDD or If you hearing about the word Test Driven Development (or TDD in short) for the first time, then you must be wondering, what the f.. is this..! How can anybody test something which doesn't even exists? or How can a test case exist without a piece of code?

Basically, its not about testing something which doesn't exists. Its about solving the problem before implementing it. Its just a good habit of writing code. Its about evolving the solution by usage. Its about understanding and defining bare minimum code requirements through functional requirement. Its about driving the design than defining the design upfront. Its about adopting to changes at highest flexibility. Its about not being a tech retard.. :P

Why am I praising TDD so much? Am I exaggerating TDD? Nope.. I'm Not! Lets figure out how TDD works and chart down every advantages of it.

Here is the problem statement.

ABC Bank Automation

A user can open multiple accounts at ABC bank. Accounts are of different types like Savings Account, Current Account, and Recurring Account. Users should be able to deposit money to any account and withdraw from their own accounts. ABC bank does not support negative balance maintenance on withdrawals.

The bank charges a monthly maintenance fee for each type of account. Maintenance fee is withdrawn for the account even if account balance is not enough. In such a case a negative balance is maintained.

• Savings account: Rs 0.00
• Current account: Rs 25.00
• Checking account: Rs 30.00

Users can also transfer money from accounts. The transfer scenarios are:

1. User can transfer money from his account to another account within ABC bank (intra-bank transfer). The bank does not charge for this transfer.
2. User can transfer money from his account to another account outside ABC bank (interbank transfer). This has a service charge associated with the transfer.
   1. <= 50,000 : Rs 15
   2. etc..

ABC Bank Account User Stories:

1. As a user, I want to be able to open a Savings account with ABC bank account.
2. As a user, I want to be able to deposit money to my ABC bank account.
3. As a user, I want to be able to withdraw money from my ABC bank account in case I have sufficient balance.
4. As a user, I want to be able to transfer money from my ABC bank account to another ABC account.
5. As a user, I want to be able to transfer money from my ABC bank account to another non ABC account.
6. As a bank manager, I want to be able to charge all the ABC accounts with appropriate monthly maintenance fee. In case the balance is not sufficient, the bank account should go in negative balance.
7. As a bank manager, I want to be able to settle the negative balance, if any, on all the ABC accounts when the deposits are made.

Let me consider first user story for the demonstration. I'm Using MSTest for this example as unit testing framework.

As per the first user story, the test looks some what like this.

Here, the test candidate is the account/account id. If you notice, through the test, I have identified few objects viz, User, SavingsAccount, Bank also an action OpenSavingsAccount. To make this test pass I have to create these objects. and this is how it looks after making the test compilable.

Solution Explorer

Now we have all required classes for the test to compile, but we don't have enough business logic to make the test pass.

After writing the required enough business logic the classes looks & the test result like this.

This process continues until all stories meet the expectations.

Will post the source code in the next blog.

Lets understand the advantages and limitations of TDD.

What are the pros?

1. It keeps a record of your code.

"Accountants practice Dual Entry Bookkeeping as part of the GAAP1 (Generally Accepted Accounting Principles).Accountants who don’t hold to the GAAP tend to wind up in another profession, or behind bars. Dual Entry Bookkeeping is the simple practice of entering every transaction twice; once on the debit side, and once on the credit side. These two entries follow separate mathematical pathways until a final subtraction on the balance sheet yields a zero. A set of books that is not supported with dual entries would be considered a mess by the accounting community, no matter how accurate and clean those books were.

TDD is Dual Entry Bookkeeping for software, and it ought to be part of the GAPP (Generally Accepted Programming Practices). The symbols manipulated by the accountants are no less important to the company than the symbols manipulated by the programmers. So how can programmers do less than accountants to safeguard those symbols?" (Uncel Bob - http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot)

2. People who follows pure TDD hardly have to debug the application - wiki

3. It helps to have he minimum required code in place. So, no effort is wasted on having code which is not required and hence, no bugs/maintenance of these code blocks.

4. It mostly kills lot of upfront design thinking time. Design of the system is evolved by test cases & code refactoring due to test fails.

5. It also acts as versioning system of your user stories. If you face an issue, all you have to do is revert back until the test case which had an issue.

6. Test first approach, pushes the developer to think how this functionality will be used by the end users. Results in addition to design by contract approach. http://en.wikipedia.org/wiki/Design_by_Contract

7. It enables flexibility. Developer now can change minimal code to fit the change.

8. No need of writing too much code for automated test cases to get the coverage. Since, your code got birth from these tests, surely all code paths must have been covered if TDD is followed religiously.

9. It acts a system document, code document & requirement document.

10. Encourages the use of Mocks & fakes to get a test passed. As your only intention is to get the test passed, you write proxies to ensure the business logic.

11. Enables you to keep cleaner exception mechanism. As every test case exists for a reason, every exception thrown will have a test case hence a reason.

12. Your code has been self reviewed thoroughly.

What are the cons?

1. It doesn't determine the success or failure of functionality as a whole.

2. Test & Code both are created by the same person.

3. It needs a substantial coding maturity to keep things simpler.

4. A change in functionality will make loads of test fails, but all of them have to be fixed than deleting them.

5. Your test & design tightly coupled. Removing test or changing the design might become an overhead.

6. It needs developer mind set change.

Over all, I believe it is a serious job and a great coding practice. If followed religiously I doubt that we encounter any code/design/quality & functionality related issues. Try it; practice it to know the benefits of it.

Please drop in your comments and suggestion.