Principles

What makes a good unit test?

• Should be well written and follow SOLID

• They shouldn’t be longer than 10 lines of code

• Should avoid logic, such as conditions and loops

• Each test should be isolated

• Should not be too specific or too general

Types of Method

• Query Methods - returns some value (could just be adding two numbers together)

• Command Methods - might change a value of an object in memory, or call a web service, or write to a database

Don’t test

• Language features

• 3rd-party features

How many tests do I need?

• As a rule of thumb there should be a test for each execution path + any other edge cases you can think of
  • 1 per if statement case

How can I make sure there are no bugs with my tests?

• For each test you should purposely try and make that test fail by modifying the source code

When not to write unit tests

1. If nobody in the team writes testable code

2. Legacy applications, that have been made with unit tests not in mind

3. Start ups