Support for test execution optimization

[odrotbohm]

Context

A common challenge for modulithic applications is that a change in the version control system triggers a build of the overall system. That build usually consists of steps that are executed for the entire system, which means: for all modules, whether the change in question actually affects a module directly or transitively.

The structural information we have about the system could be combined with knowledge about the change set at hand to identify which modules are directly affected by the change itself. We could then find out about all modules directly or transitively depending on the "dirty" modules and limit the test execution to filter test cases contained in those modules only. Similarly to limiting the parts of the application that are actually bootstrapped during module-specific test via @ApplicationModuleTest.

Ideas

JUnit 5 has dedicated support to hook into the test discovery process, i.e. it should be possible to place a JAR in the classpath of e.g. the Maven Surefire execution that filters the test cases to actually be executed.

We also need to find a mechanism to identify, what the set of changes is, we want to start from. During local development, this is likely to be the files currently considered changed by Git. During a CI run (the more important aspect) it's likely the last change set or the set of change sets in between the previous build and the current one.

Original ticket:

• Investigate support for build time optimization moduliths/moduliths#174