Allways start with failing test!

Traditional TDD consists of three steps:

1. Write a failing test
2. Implement your code
3. Write a passing test

Those steps are known as "red green" refactor.

In some cases, you need to add test to existing code, so you have the option to write a test which pass in their first run, my advice is don't go for it! I made this mistake, and therefore I am trying to warn you.

Why is writing a failing test a must?

It's not because of refactoring agenda which favors baby steps. It's because you may be writing a test which always passes! And the risk that you may feel comfortable with your code, when you're actually naked!

The chances of writing tests which always pass are going up when using non-trivial code inside the test, for example, using a mocking framework or using a dependency injection framework inside the tests.

It happened to me more than once, so don't take your chances: simulating a failing test is vital!