TDD. The tip of iceberg.

...write unit tests before the writing production code.

Three Laws of TDD (R.C. Martin)

• You may not write production code until you have written a failing unit test.
• You may not write more of a unit test than is sufficient to fail, and not compiling this failing.
• You may not write more production code than is sufficient to pass the currently failing test.

The tests and the production code are written together, with the tests just a few seconds ahead of the production code.

Keep the tests clean.

What makes a clean test? Three things. Readability, readability, and readability...

Clean tests follow five other rules that form the F.I.R.S.T acronym:

• Fast - Tests should be fast.
• Independent - Tests should not depend on each other. 
• Repeatable - Tests should be repeatable in any environment. 
• Self-validating - The tests should have a boolean output. 
• Timely - Unit tests should be written just before the production code that makes them pass.

Given-when-then approach.

Given-when-then approach supposed to make your tests more readable:

• Given - a context <some initial context...>
• When - a cause <something happens...> 
• Then - an effect <some expectation...>

Given roulette bet is 7

When spin result is 0

Then you have to lose :(

Whatever, the context can be expanded via using And in between:

Given a list with 3 items

When i add another item

And chek count of items
Then the count should be 3.

By thinking in terms of these three parts of behavior, we may arrive at different circumstances (given) at which the behavior happens, or additional ones that are needed. The same goes for triggers (when) and effects (then).

What else?

@see TDD, ATDD, BDD...