Testing

In the prototyping stage, ORKG did not see much testing effort. We work to improve the situation continuously by providing tests for newly written code and areas of the code that are modified and currently lack test. Developers are expected to provide tests with every merge request.

There are currently two types of tests: unit tests, found in the test module, as well as integration tests, found in the integration module.

Unit tests should make out the largest portions of test, as described in the test pyramid. They should be written in accordance to the FIRST principle (see here and here). Because test code is code and therefore needs maintenance, only just enough test should be written. A good guideline it the one proposed by Sandi Metz, as summarized in this write-up and her talk at Rails Conf 2013. All code should be written with testability in mind since testability is a good indicator for code quality: clean code is usually easy to test.

Some of the tests in the test module could be considered integration tests, as they instantiate some parts of the Spring Boot framework. Due to their short runtime, no effort was made (yet) to separate them into a module of their own.

The integration tests are designed to test the full system as closely as possible to the production system. They therefore use Docker containers during the test runs, using TestContainers. This results in an increased start-up and run time which slow the testing cycle down and should only be used for testing all components, start to finish. They are additionally used to generate the API documentation using Spring REST Docs to ensure the API is in accordance with the rest of the system.

Testing in Spring and Spring Boot is a complex topic due to the complexities of the framework. To get started, the following articles from the "Reflectoring" blog are a recommended read:

Another useful source is the chapter on testing in the official Spring Boot documentation.