ChatGPT couldn't help me this time, so here I am.
I am struggling to design a good implementation design for my integration tests. Let me tell you the simplified story of my problem step by step.
- I created a maven module A with authentication features.
- I unit tested everything, not an issue there.
- I wanted to make integration tests
- To make good integration tests, I had to create utility classes for context. In this case, let's consider the class "AuthenticationClient" (that communicates through HTTP on localhost).
- I put these utility classes in a context package in the integration test sources so I can use them for said tests.
So far so good, here's where my dilemma comes from.
- In another module B, I use the authentication feature of module A (which therefore is a dependency)
- I wanted to make integration tests for module B
- In this integration tests, I need to authenticate, so I need to make an AuthenticationClient
- Since duplicating the class is absolutely out of question, I need to extract this class from module A test source to a common module (since I can't use a class that belongs in the test sources of another module)
- So I naively created a module C for AuthenticationClient (and other utility classes)
- Since AuthenticationClient depends on classes from the main source of module A, module C requires module A as a dependency.
- Now the fun part, since i've extracted some test context classes from module A to module C (e.g. AuthenticationClient), I need module C as a dependency (test scope) for my integration tests of module A, hence the circular dependency.
Unsurprisingly, it can't work even if the scope is not the same. I can't really see any option there. As long as I'm extracting the code I want to avoid duplicating, I inevitably create a circular dependency.
I tried creating a submodule but it doesn't work either, and having sources in a parent module is dirty.
One solution I thought about was creating a module only for the integration tests, without main source code, but that's not really pretty either, knowing that in this scenario I'll still have to extract the contexte classes to a separate module...
Does someone have a better idea?
Here's a little schema of the dependency I want to achieve (plain arrow represent a plain dependency, dotted arrows are internal/implicit dependencies) :
There are virtually no circular dependencies, which makes me wonder why maven complains about them
Edit : I will ultimately have to test these test utility classes, so just packaging them from the test sources won't do. I need to put them in the main sources of a separate module to be able to test them
Edit : I might have found a workaround. Actually I should be able to make the test context classes completely independent from the module they're supposed to help testing. I think that's even better, since it will make the test completely independent from the main source (not even using POJOS from them). I'm not sure if it's possible though, so other options would be extremely helpful there
That might be wrong assumption. You can craft attached artifact (with separate classifier
tests) in common module that you can include intestscope, which will include test code.https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html
https://maven.apache.org/guides/mini/guide-attached-tests.html