Multimodule tests which depends on each other

Question

I'm currently writing integration tests between 2 modules:

• Module A - contains a REST service which can be dockerized via maven plugin
• Module B - contains integration tests which depends on Module A docker to be up and running

So I used failsafe plugin which contains the pre-integration-tests phase and post-integration-tests.

In the pre-integration-tests I start the dockers and after all the integration tests of all the submodules have finished I want to kill those dockers.

In the docker plugin that I use (fabric8) there is also 2 phases which I use in the above phases which area docker:start and docker:stop

The problem appears when I run the entire project, the dockers are killed in Module A before Module B tests are running, so I thought that if I could tell the parent module which holds them something like :

• Start Module B docker:start plugin
• Run integration tests of all project
• Start Module B docker:stop plugin

It would really solve my problem, but is there a way to call phases of submodules from parent module or even revered, attach a submodule phase to the parent module phase from the submodule

Answer 1

To my knowledge, Maven doesn't have the ability to pause a module's build until a condition in another module is met; Maven runs a sub-module's build fully before going to build another sub-module.

You can however, make Module B depend on Module A (even depend on a set of test classes from it), and thus you could start your REST Service, within the build of Module B, as part of your integration tests.

Answer 2

As far as I understand your setup, building Module A has nothing to do with starting/stopping containers; thus, Module A shouldn’t do it.

Instead, the container should be started and stopped in Module B’s pre-integration-test and post-integration-test phases, respectively. After all, Module B’s integration-test phase needs a running container, not Module A.

If you are not used to Maven’s (opinionated) way of doing things, this may seem unnecessarily restrictive, but Maven merely forces you to do the Right Thing. Think about it like this: If, in the future, another Module C also needs a running docker container, e.g., to run some other tests against, you wouldn’t want to recycle a single docker container (started by Module A). As this risks Module B and Module C interacting in funny ways, each module should get its own docker container to work against.