Reference: TDD Habits

TDD habits

General rules

• Tests should test one thing only

• Test one logical assertion

• Don't refactor with failing test (don’t refactor on red)

• Organize your unit tests to reflect your production code (similar project structure)

• Keep your tests and production code separate

Red

• Create more specific tests to drive a more generic solution (triangulate)

• Give your test meaningful names (behavior / goal-oriented) - that reflects your business domain

• See the test fail for the right reason

• Ensure you have meaningful feedback from failing tests

• Write the assertion first and work backwards

• Organize your test in Arrange, Act and Assert blocks

  • Arrange (aka Given) – all necessary preconditions and inputs.

  • Act (aka When) – on the object or method under test.

  • Assert (aka Then) – that the expected results have occurred.

  • Structure the code in tests to reflect these concepts.

Red -> Green

• Write the simplest code to pass the test

• Write any code that makes you get to the refactor phase quicker

  • It is okay to write any code that you might improve at a later stage

• Consider using Transformation Priority Premise

Green -> Refactor

• Treat tests as first class code

• Use the Rule of 3 to tackle duplication

  • Code can be copied once, but that when the same code is used three times, it should be abstracted. Or if you need something once, build it. If you need something twice, pay attention. If you need it a third time, abstract it.

  • Keep in mind that duplication is cheaper than the wrong abstractions

• Consider using object calisthenics to refactor your design