Definition
TDD by now is a well known buzzword that has been around for some time.
TDD is a deferent way to start your coding tasks. The idea is to write tests before implementations.
Don’t write code without having a failing automated test.
Process
So the process of TDD generally speaking is:
- Write the test code.
- Compile the test code (it should fail).
- Implement just enough to compile.
- Run the test and see it fail.
- Implement just enough to make the test pass.
- Run the test and see it pass.
- Improve the code for both the tests and the implementation code.
- Repeat from the top.
Basics
It is important to state that TDD’s main objective is not testing software! This is merely just a side effect.
There are couples important issues related to TDD:
1) Simple design
Because the tests define the requirements, your job when writing the code should be to satisfy the requirements no less and no more.
Everyone understands no less (the program would not work otherwise), but not everyone understands no more. What is meant by no more? Think back to a time when someone asked you to add a feature to an existing system, and you said “No problem; I thought this was going to happen and put additional code in for this specific purpose.” You were viewed as a hero because you anticipated the requirement and had already implemented the solution.
Now remember a time when you added complexity in the form of additional functions, abstract classes, and so on that nobody ever asked for. This additional code has to be maintained along with the rest of the useful software. In fact, the maintenance burden of this software is worse because it is not supported by real usage. So you should always strive to do no more and no less, as follows:
The code is appropriate for the intended audience.
The code passes all the tests.
The code communicates everything it needs to.
The code has the smallest number of classes.
The code has the smallest number of methods.
2) Break it down
My mom told me that if I will cut my chicken *** into small pieces, it will be much easier for me to swallow. The same goes here.
Solving big problems is hard and solving them all at once is harder. Thus by breaking the task into smaller tasks, it will be much easier to implement and verify that correctness of the code and putting them all together, we will get the entire task.
Summary
So, some of you may have used it some of you may just heard of it. The bottom line is that this is exciting development methodology that has become more commonly used. You write you tests and then you implement the required code. The tests verify that the code in term of functionality aspects works as expected. My way of looking at the tests as to the TDD, is as “Functionality and behavioral tests’.
