How writing Unit Tests forces you to write Good Code: And 7 bad arguments why you shouldn’t

Unit Testing is about writing good, well-designed, decoupled code that, as a result, is automatically testable.

Good Code is code that works well and is easy to maintain, extend, comprehend and understand (in the present and in the future).

The following (well-established) practices are important:

  • Reduce coupling
  • Maximize encapsulation
  • Single responsibilities
  • DRY
  • Open/closed
  • Documentation
  • Use design patterns

What is a Good Unit Test?

  • Tests only your class, not it’s depedancies
  • Input/output checks
  • Hypothesis-based
  • Concept-based
  • Small
  • Intuitive
  • Uses business/domain terminology

Reasons why you should not write a unit test:

  • ‘Unit testing takes too much time or is too difficult’
  • ‘Unit testing is a luxury (we don’t have)’
  • ‘Unit testing is not necessary, because I already write Good Code’
  • ‘Unit testing is not possible with this legacy code’
  • ‘I don’t have enough knowledge of Unit Testing’
  • ‘Unit testing are inferior to regression/integration/manual tests’
  • ‘Someone else (like a tester) can write tests for my code’

Read the complete article here: