TDD - motivations

Ive been watching a few videos on this topic by Robert c Martin. His three laws are:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

He mentions the following "minor" reasons:
 - Halve your debugging time
 - Serve as documentation
 - Improve you designs
 - Its fun


Halve your Debugging time
 
Following the three rules you'll never be more than a minute away from knowing that  you code works. You can easily undo the last line you when something doesn't work

Serve As Documentation
Third party come with a pdf guide. What is the part that we really look at? The sample codes. Unit test are simple to understand, they show every possible way to invoke an API, and they are executable, so they are always in sync, they are the perfect documentation!!

Improve your design
Writting test after your works it's quite hard because the code is not testable, its too coupling to something, and its hard to break that coupling.
Following the laws you can't write production code that is hard to test, because you wrote the test first. "Your code is testable or decouple, simply by writing the test first you end up you wind up your production code in ways that you never thought before. You end up with a better design".

Its fun
Becuase the test fail and  you want to make it pass. You get to write a test and make it pass, write another test and make it pass...


Main reason
Bad code,
why do you write it? we have to go fast.

Why don't you clean it? How many times you look at a code and think I need to clean it, next thought is I don't want to break it?

You are scared from breaking it. If you break you own it. So you don't touch it. So system continues to get worse and worse, slowing you down, slowing your team down till eventually the project gets through away and fresh new project starts.

How do we get reed of that fear?
Imagine we have a button, and when you push it within a few seconds a green light will tell you everything works.

"If you have the button, you'll not be afraid of touch, if you touch it will get clean, if it gets clean the team will go faster and thats why we do it."

How is stupid is to be scared from the code write, how bad is to not make a change that improve you code,  how unprofesional?

The only way is to have a suite of test that you can trust. You can trust your unit test if test everything.

Code coverage tool?
The goal is a 100%. You can't reach it but we try to get as close as possible.