Test driven development (TDD) has become popular over the last few years. Many programmers have tried this technique, failed , and concluded that TDD is now worth the big effort it requires. Some programmers think that, in theory it is a good practice but that there is never enough time to really use TDD, so that is why many think it is basically a waste of time.
What’s the reason to use TDD?
There are studies, and discussions about how effective TDD really is. Even though it is definitely useful to have some numbers, I don’t think they answer the question of why we should use TDD in the first place. Features can be tested manually with the browser, but is that enough? So that is why you can use TDD because it is the simplest way to achieve both good quality code and good test coverage.
The TDD cycle
1. Add a test
Each new feature begins with writing a test. Write a test that defines a function or improvements of a function, which should be very succinct.
2. Run all test and see if the new test fails
This validates that the test harness is working correctly and shows that the new test does not pass without requiring new code because the required behaviour already exists.
3. Write code
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect and may for example pas the test in an inelegant way.
4. Run Test
If all test cases now pass, the programmer can be confident that the new code meets the test requirements and does not break or degrade any existing features.
5. Refactor code
The growing code base must be cleaned up regularly during test-driven development. New code can be moved from where it was convenient for passing a test to where it more logically belongs.
6. Repeat
Starting with another new test, the cycle is then repeated to push forward the functionality.
REFERENCES
https://medium.freecodecamp.org/test-driven-development-what-it-is-and-what-it-is-not-41fa6bca02a2
Olles blog 
