Unit tests for ONOS are built using the JUnit framework, version 4.11. Unit tests are used to verify correctness of implementations and are run as part of every full build of ONOS. The nightly SonarQube build runs all of the unit tests and produces coverage data that can be seen here.
Unit tests should be as short, fast and reliable as they can be. Every developer on the project will be running your tests, they should be easy to run and produce accurate results. Here are some key ways to write tests that are not brittle:
- Don't use sleep(), since it often leads to brittle tests. If you find that you have to wait for an event or wait for some work to be done by another thread, prefer latches or thread notifications to sleeps.
- Try to keep individual tests small, and only test one thing per test.
- Use mocking when you need to include a complicated service to satisfy dependencies.
- Maven may choose to run multiple tests in the same Java virtual machine. If you use static variables in classes, be sure to reset them to known starting values before each test runs.
- Do not use local resources like files and IP Addresses in tests.
If you add a class, consider adding the following basic tests for it first:
- Any class that defines equals(), hashCode(), or toString() must test these methods. The Google Guava EqualsTester class provides full coverage for these methods:
- Utility test methods are provided to assure that classes are properly defined immutable classes, immutable base classes or utility classes. Using these methods will assure that other developers don't make changes to your classes that violate your assumptions.
- A basic test for each one of your constructors and a check for the values returned by data access methods should always be included:
Hamcrest is a powerful framework for defining matchers for data values in tests. ONOS uses version 1.3 of Hamcrest. Contributors are encouraged to learn about and use the Hamcrest framework, particularly when working with arrays and collections.