What happens when you have tests that need different resources with similar names?
Confusion, that’s what. Let’s map out a project so we can see what happens:
- Parent Project
- Test Resources 1
- Test Resources 2
- Library Code (depends on both test resources projects)
Now, in our problem code, the resources for the test data use the same names, so the library code won’t be able to deterministically work out which set of data is being used.
How does one work around this?
The first, and probably best, solution is to use a different build tool, one that gives more finely-grained control over the build lifecycle: Gradle comes to mind.
The other solution involves a little more work, and probably would be classified as a Maven hack.
What you would do is fairly simple, but verbose; you’d add two more projects, as integrations for the library and the dependencies, like so:
- Parent project
- Test Resources 1
- Test Resources 2
- Library Code
- Integration Tests 1 (using Library Code and Test Resources 1)
- Integration Tests 2 (using Library Code and Test Resources 2)
The problem with this kind of structure is that the Library Code project no longer has its own complete test structure; it can pass all of its own internal tests, without actually passing the integration tests, because those are in separate modules. Therefore, one might be tempted to write off failures in the integration test modules, and publish a flawed artifact to a central repository.
Again, the best approach is probably Gradle.