Don’t write tests for production code, write production code for tests

Always start with a test

Focus on what you want to your production code to do and then express it by a test scenario. When the test case fails add or change some production code. When the test case gets green do some refactoring if you think there is a need. Then choose the next scenario you want to implement and start the process again.

In the beginning commit to this rule blindly. It will pay in the future.

There might be several exceptions to this rule such as prototyping for example. Remember that prototype should not become production code in most cases. If you prototype you should delete the code as soon as the prototype is ready unless you feel that you are willing to commit to pay the technical debt and the interest for the technical debt along the way.
For me prototyping is most often getting to know how third party APIs work. But in that case I also often just write tests for the third party API and then I am sure I know how it works.
But, since you are new to TDD this was just an example for you when TDD might not be the best way. You, keep doing TDD! 🙂

Any comments? Please comment! 🙂

Recommended idea for today:

Recommended book for today:

Clean Code: A Handbook of Agile Software Craftsmanship