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.