Building modular codebases also involves testing. The Java community has always fostered a strong culture of automated testing. Unit tests play a large role in Java software development.
What effect does the module system have on existing testing practices? We want to be able to test code inside modules. In this chapter, we look at two common scenarios:
Test modules from the outside. Blackbox tests exercise the public API of a module, without knowledge of internals (hence, the box is opaque). The tests can test either a single module or several modules at once. As such, you can also characterize these tests as integration tests for modules.
Test modules from the inside. Instead of taking the outside view, whitebox tests assume knowledge of the internals of a module. These tests are typically unit tests, testing a single class or method in isolation.
Although other testing scenarios are possible, these two cover a wide range of existing practices. Blackbox tests are more restricted in what they can test, but are also more stable because they exercise public APIs. Conversely, whitebox tests can test internal details more easily, at the risk of needing more maintenance.
The focus of this chapter is to highlight the interplay between testing and the module system. It is expected that build tools and IDEs will take care of a lot of the details described in this chapter. Still, it’s important to get a feeling for how ...