Test Driven Development, What is that?

In this story, I want to share about Test Driven Development (TDD), TDD has become more popular over the last few years, much of company use the TDD concept with its own way. In this article I want to share about my knowledge in TDD.

http://bellintegrator.com/catalog/view/theme/bellOne/image/products/Test-Driven-Development.jpg

What is TDD?

TDD is an approach to develop software which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.

3 Laws of TDD from Clean Code book:

First Law, you may not write production code until you have written a failing unit test.
Second Law, You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
Third Law, You may not write more production code than is sufficient to pass the currently failing test.

Why should we use TDD?

Actually, you may not using TDD if you are not trying to be a better engineer (Professional Pragmatic Engineer). Wait, what? Yes, you should only use TDD if you try to be a better engineering which write better code (Clean Code), and have more confident to what code.

1. Gain More Confident From Your Code
   First benefit, how do I get more confident by using TDD? as a part of TDD, you should make a test first (a test which specify your input and output), then see your code become red, and then you make it pass, and see your code become green (Red Green part of Red Green Refactor of TDD), how you can’t confident with that part of code which you have make a specify and expectation of what you want. That part of process should make you confident, if you give an input to that function, that function will return what you want.
2. Break Problem Into Small Chunk
   Second benefit, from using TDD, is that you will be able to split/break a problem into smaller chunk/part. So you able to think step by step, how to solve the problem, and you will able to think about the algorithm bottom up/small to big.
3. Clean Code, Clean Test, Clean Solution
   Third benefit, from using TDD, is that your test will be better, you will not think about test after you finish your code, and you will have more readable test and code, because what you write is only what you need.
4. Documentation
   Fourth benefit, you will be able to see your code and test as Documentation for you, as a programmer. Unit Test/Spec describe the lowest-level design of the system, they are unambiguous, accurate, written in a language that the audience understands, and so formal that they execute. What professional would not provide such documentation?
5. Good Design
   When you follow the three laws, you will have dilemma of testing code that doesn’t exist. But when you are doing that, you will found that you forces your self to think about good design, and preventing your code to have a bad huge of coupling.
6. Tracking
   Sometime you will found your self being confuse of what you are doing, or what have you done yesterday. By using TDD you will have an automatic tracking for your self, when you run your test, you will know and have better context, rather than writing lines of comment inside your code.

When should we use TDD?

As I said before, if you want to be a better engineer, confident with your code, and have a better code (Clean Code), you should start to use TDD as soon as possible (read: now). But if you are trying to have an excuse about that, if you think that you are smart enough and confident enough with your own code without using TDD, then you are an overconfident person, and not realistic/pragmatic person. As an example, see your old code (more than 6–12 months untouched code without test), do you have any confident to change that code without break anything?

How to do TDD?

As you see in picture above, you should have an image in your mind about how to do TDD. Yes, it’s simple to think, but a little effort to do it firstly. You can do TDD by using this simple step.

1. Create a simple specification of your function (what is the input, and what is the output)
2. Run test, and see that test fail your logic/function
3. Create an Implementation, and Try to pass it as simple as you can
4. Run test, and see that implementation pass your test
5. Commit your changes (it should be two files change, one is your test/spec, another one is your implementation)
6. If you see that you can make it better, you may do Refactor
7. Run test, and see that refactor not break any behavior of your application
8. Commit your changes (it should be only one file — your test/spec only or your implementation only)

If you see that is 2 part of commit, first, after you make the code pass your test. second, after you refactor your code/test/spec.
It’s easy to make sure that when you change a code, you didn’t break any of your existing behavior; you just have to run the test again and see nothing’s break. But, how to make sure that when you change a test/spec, you didn’t break any of your existing test? if you just run the test, you will only know, oh it’s the code still pass the test, but after you change the test, you will not known if the test didn’t cover every code that have been cover before.
By using any of Code Coverage tool to see your percentage of code coverage, you will know if you are not break any previous test and still cover every code that have been covered before. But how? because you will see your code coverage percentage. if it still 100%, so you still cover all the code by using that test, but if its become 98%, you will know that your test cannot cover what it have covered.

Test Concept from Clean Code

First, Keep the Test Clean (don’t make your test dirty of code)
Second, Clean Test (Increase your readability of your test)
Second, One Assert per Test / Single Concept per Test (SRP from SOLID)

Using F.I.R.S.T Concept for test, you may see what is that and what is the explanation from the given link. as Summary F.I.R.S.T concept is Fast, Independent, Repeatable, Self-Validating, Timely.

What Next?

If you have known about TDD and have practice TDD, you can go to the next phase. What is the next phase? the next phase is trying to make your code and commit, express their intent. You may learn it from Meaningful Names from Clean Code from Martin Fowler. You should know about ping pong games (from clean coder) in practicing TDD, it will make you do TDD in Pairs better.

Source:

Clean Code, by Robert C. Martin

Clean Coder, by Robert C. Martin

SOLID Principles: Single Responsibility Principle - DZone Java

Introduction to Test Driven Development (TDD)