TDD and BDD

Audio blog on TDD and BDD


TDD:
TDD-->test driven development
Adhering to tdd means you shouldn’t write a line of code without developing test case for it first !!
For beginners this may be very difficult...sometimes we write functional code without writing test cases. That’s not correct TDD.
It’s a technique where we use unit tests to drive the design of the program or project.
Unit tests ??
    These are very small scripts which send some input to a class or method and verifies if the result is same as the predicted result.
For example , suppose we have a function to concatenate two strings, we test it like,
START TEST
    assert(concatenate(“hello”,”world”),”helloworld”,”expects helloworld as output”);
END TEST
Forget the syntaxes used above, they are invented by me now to explain testing.
There are different testing frameworks available for carrying out testing in different programming languages.
Java - JUnit
C - Check
...

How TDD works? or Motto of TDD..
RED ---> GREEN --> REFACTOR

RED --> Develop a test case and make it fail. ( a test case will obviously fail without even writing the function it is testing)
GREEN --> develop code so that the test case developed in the first step passes.
REFACTOR --> Change code to remove duplication(accept it.. there will be some sort of duplications even in experts code) , improve the design.

It's to be noted that testing is to be done after refactoring to verify everything is working correctly.
This is done for every piece of code that is going to be a part of your project.
Getting the point?
You develop test cases based on requirements and then write code to pass those test cases . This is the essence of TDD.

Why use TDD ??
You may think you are good at designing and then implementing the same. But that may not be the case. May be you are a gifted programmer and designer.. ! but that may not be the case with everyone. TDD makes sure that the code you write is good. You will understand if i explain some advantages of TDD,
Advantages:

• It helps you in proceeding step by step. The important thing is that it gives you confident that the step you completed is perfectly working and correct. Some programmers tend to code many many lines of code and then wonder where the bugs are !! it's always better to go step by step.
• It forces decoupling of modules or dependencies. For example , you write a program to find multiplicative inverse modulo of a number. This program in turn needs to calculate gcd of the number and the modulo involve. Normally you tend to write the code to calculate the gcd within the main module itself. So they become coupled. If you need to find gcd of two numbers in some other program you need to copy paste the code. Had you used TDD you would have developed test cases to check whether the gcd algorithm works correctly. Automatically you would have put the gcd algorithm as a separate module. Decoupling happens !!
• The test cases are like a constant feedback to the developer that the modules are working properly. Again it's for the confidence of the developer. It helps in easily identifying and fixing bugs too.
• It is like a documentation that never goes out of date unlike the documentation developers write !

BDD:
It stands for behaviour driven development. It involves identifying behaviour of a system and then writing test cases for that behaviour to be satisfied. It combined acceptance testing and unit testing.
People consider BDD as rephrasing the existing good testing process based on TDD. Am not going into BDD any further as i have zero experience in them.

Where TDD may go wrong? or what led to BDD when we have TDD !!
TDD may have design impacts (not always.. happens due to bad programming logic or poor design knowledge of the programmer). Sometimes design may not be clear to the coder. In those cases you need to change the test case itself which may prove very costly.
Lot of time investment is involved to get into the TDD approach. Normally you can see developers skipping test cases for some part of the code or project .

TDD approach by example:
    Let’s assume you are writing a simple 2D game... like mario.
As you are considering game as an example test cases will be innumerable. I will tell only a few here.
When mario gets a mushroom,
    if he is small he must become big
    if he is big then he must get firepower

Now you decide to put this into code, you decide to write a mushroom_got function which gets called when mario gets a mushroom.
so you start by writing test cases.

testcase 1:
input : small mario gets mushroom
result: big mario

test case 2:
input: big mario gets mushroom
result: mario with firepower

Now you begin implementing methods that does the same. You then find that becoming big or getting firepower also needs to be tested.

so you write test case for those like,
after becoming big -- is height of mario larger than his prev height etc..

for implementing this testcase you will write makemariobig as separate function and then use it inside the mushroom_got function.

This is how TDD works. You can understand how it helps in deciding the flow too.

That’s it for today. See you in next post.