It’s commonly used practice to declare all project dependencies under implementation configuration.
What I need is a custom testing suit (integrationTest let’s say) and of course I need an ability to reach any dependency of my project in my integration tests. So I end up with smth along these lines:
But then in my integration test I do need to have libA in my compile class path. I actually need all libs my project depends on. My test is going to be:
@Test
fun test_it() {
val testData = functionFromLibA()
functionFromMyProject(testData)
}
But it doesn’t work this way. None of implementation dependency seem to be available under my integrationTest source set, which is sad.
I would say this behaviour makes testing suites not really useful feature. You almost always want to have all classes you project depends on in your tests (to bootstrap some test data)
of course I need an ability to reach any dependency of my project in my integration tests
That is not “of course”, it highly depends on the kind of tests like for example blackbox tests vs. whitebox tests.
None of implementation dependency seem to be available under my integrationTest source set
Of course not, if they are implementation dependencies, they are just for the implementation and do not leak into downstream compile classpaths.
I would say this behaviour makes testing suites not really useful feature.
That’s not really right, as you can easily change that.
You almost always want to have all classes you project depends on in your tests (to bootstrap some test data)
No I don’t. You might. But as said above this heavily depends on the type of tests like e.g. white-box vs. black-box tests. And while it is easy to set it up like you expect it to be, it would not be so trivial to un-configure it if it were the default.
Make the integ test implementation configuration extend from the main implementation configuration and you get the result you want. Something like
Yeah, I like your point. Agree, not everyone might need to access implementation classes in a test suit.
I was super confused, because I recall that on Gradle 7+ implementation dependencies classes were on the classpath of a test suit by default. May be they changed that in 8+, or I am confusing something and test suits haven’t been working like that ever.
Anyway, thanks Björn!
At least I’m not aware of any change in that regard.
Maybe you think about the default test suite?
Because for that you have exactly that and the same for the runtimeOnly dependencies.