As a developer, we are sometimes so excited to build functionality that we forget to write tests to verify that the code works as expected, and to protect against future regressions or changes that break functionality. Have you heard this excuse before: I'll get to the tests after I write this one function and push it to production?

Test driven development (TDD) strives to enforce testing before writing a single line of code. In other words, you write all production code in response to a test case.

In the Test Driven Development course offered by the IBM Cloud Garage, there are four rules of simple design to live by when developing using TDD:

Passes the test

This is simple, but does the test pass? This is the canary in the coal mine analogy: if a test fails, something went wrong. If the test passes (and the test has been proven to test appropriately), the expected behavior is still the actual behavior.

Reveals intention

Code should be readable and clearly defined. Can someone look at a piece of code and clearly understand what it does without having to read comments or documentation? Use well named variable, method, and class names.

No duplication

You may have heard the acronym DRY (Don't Repeat Yourself) before. This rule helps to keep code concise and as the name implies, avoid duplicated concepts. If there is the same code, can you refactor it into a new method?

Fewest elements

Step back and look at the bigger picture. Are there unused pieces that aren't used? Remove any unused code. Avoid over engineering or planning for the future. TDD strives to write the minimum amount of functionality to pass the test.