[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:
Resources:
https://stackify.com/unit-testing-basics-best-practices/
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
Post a Comment