[Unit Testing] Best Practices of Unit Testing

1. Arrange, Act, Assert

Think of each test as a hypothesis, and your test run as an experiment.

Arrange; instantiate an object.
Act; invoke a method and capture the reuslt.
Assert; assert the hypothesis to prove it correct (or wrong).
(You should 'tear down' after these 3 As)

2. One Assert per Test Method

Don't have to be strictly followed, but a general guideline.
Beginners have a tendency to try to test everything in one test method.
But it'll be hard to pin down all the errors at once.

3. Avoid Test Interdependence

Each test should handle its own setup and tear down.
The test runner you use might execute several tests in parallel, and therefore, you don't want one test to depend on another test's state.
While your test runner might execute your test in a particular order today, it might execute it in a different order tomorrow.
To avoid confusion, just avoid test interdependence.

4. Keep it short, sweet and visible

Resist the impulse to abstract test setup ('arrange' step) to other classes, and especially resist the impulse to abstract it into a base class.
(To abstract to other class means to create a new class to mimic the original class - just use the original class).

When a test fails, you want to understand what went wrong. Remember that you want to test the production code, and unit test does just that.

5. Recognize Test Setup Pain as a Smell

If you find that the "arrange" part of your unit testing becomes cumbersome, stop what you're doing, and look at the design of your code - specifically its modularity.
If you find it hard to get a class and a method setup so that you can test it, then you have a design problem!

Remember that tests carry a maintenance weight, just like production code (meaning when a future developer changes the actual code in the future, they have to change your unit test as well. And you don't want them to go through the hard stage of getting everything setup).

6. Add them to the build

Do this as early as possible.
A build should fail if the unit tests fail; no ifs, no buts, no exception.
Your team will eventually start ignoring the failures when the pressure to deliver mounts.

7. Don't overtest
Consider avoiding unit tests when:

  • Elaborate frameworks need to be created or installed just to get the tests to work.
  • The tests are applied to the code that, if broken, has very little bearing whatsoever on the overall software quality.
  • The costs of maintaining the set of tests are higher than the cost of maintaining the actual product code.
Consider writing unit tests when:
  • The logic behind the method is complex enough that you feel you need to test extensively to verify that it works
  • A particular code function breaks and it takes longer than a minute or so to fix it.
  • It takes less time to write a unit test to verify the code works, than to start up the system, log in and re-create the scenario.


Resources:
https://stackify.com/unit-testing-basics-best-practices/
https://www.javaworld.com/article/2892225/testing-debugging/how-just-about-everyone-gets-unit-testing-wrong.html

Comments

Popular posts from this blog

[Redis] Redis Cluster vs Redis Sentinel

[Unit Testing] Test Doubles (Stubs, Mocks....etc)

[Node.js] Pending HTTP requests lead to unresponsive nodeJS