Execution order of test phase in multi-projects with dependencies

I am looking at how multi projects are managed as seen in the official documentation: http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:multiproject_build_and_test

Specifically, the behaviour document in example 56.29 doesn’t seem to make sense when it comes to sequencing of :shared:test relative to :api:test. It is obvious that :api:compileJava cannot happen until :shared:compileJava followed by :shared:jar as the api project needs the artifact from the shared project. I would assume that the unit tests of the api project should not be run unless the tests of the shared project also pass.

The reason why I ask for this behaviour is as follows: the api module assumes the correctness of the shared module. If there are bugs in the shared module, then they could cause unit test failures of the api module as well since the assumptions being made are violated. Running the tests against the shared module and then running the tests against api ensures that the shared module is bug free (to the extent the unit tests can verify) before even starting to test the api.

The current flow as resulted in spurious errors being reported on projects wherein changes done to the shared module breaks its own tests but what gets executed first is the api test which falsely reports that the api module is broken.

The fact that api depends on shared doesn’t imply any relationship between their respective test tasks. You will have to be explicit here. There are two options.

  • If you always want to run shared tests if api tests are run:
test.dependsOn ":shared:test"
  • If you want to run api test before shared tests but only if both are required by the build:
test.mustRunAfter ":shared:test"
1 Like