Best Practices for Unit Test Case Automation

Make each test orthogonal (i.e., independent) to all the others

• Any given behavior should be specified in one and only one test. Otherwise if you later change that behavior, you’ll have to change multiple tests

Don’t make unnecessary assertions

• Which specific behavior are you testing? It’s counterproductive to Assert() anything that’s also asserted by another test
• It just increases the frequency of pointless failures without improving unit test coverage at all
• Have only one logical assertion per test
• Unit tests are a design specification of how a certain behavior should work, not a list of observations of everything the code does

Test only one code unit at a time

• Architecture must support testing units (i.e., classes or very small groups of classes) independently, not all chained together
• If you can’t do this, then your architecture is limiting your work’s quality – consider using Inversion of Control

Mock out all external services and state

• You’ve definitely taken a wrong turn if you have to run your tests in a specific order, or if they only work when your database or network connection is active.
• Behaviour in those external services overlaps multiple tests, and state data means that different unit tests can influence each other’s outcome
• If you can’t, at least make sure each test resets the relevant statics to a known state before it runs.

Avoid unnecessary preconditions

• Avoid having common setup code that runs at the beginning of lots of unrelated tests

Don’t unit-test configuration settings

• By definition, your configuration settings aren’t part of any unit of code

Name your unit tests clearly and consistently

• Avoid non-descriptive unit tests names such as Purchase() or OutOfStock()
• One naming convention could be - Action_ConditionsToTest_ExpectedResult. Example: ProductPurchaseAction_IfStockIsZero_RendersOutOfStockView()

Follow consistent test structure

• Setup -> Action -> Assert -> TearDown