If you are doing unit testing, all you presumably care about is the classes themselves; not the configuration. I would think that tests which care about configuration - including what classes are accessible - is properly a functional test.
So, why not simply handle unit tests, as you say, with everything on the class path - and then also do functional tests with those tests in a separate package so that they are subject to the same access rules that any outside code would experience? We want unit tests in the same package as the code they are testing, not only to make the correspondences clear, but also so that we can access package-private class members, but that isn’t the case for functional tests. Russ > On Nov 25, 2016, at 5:48 AM, Robert Scholte <rfscho...@apache.org> wrote: > > On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax <fo...@univ-mlv.fr> wrote: > >> setting command line arguments or using a build tool to fiddle them for you >> is exactly what we do not want here! We want fidelity between the compile >> time configuration and the runtime configuration. Having to play with >> -Xpatch at runtime is conceptually exactly like setting the classpath. I >> don't want to explain to the Java devs that we have fidelity between >> compile-time and runtime on source code but not on test code. > > I agree on this one. I've been thinking about this a lot and I'm wondering if > this is a Java issue or test-tool issue. > What I see with JUnit is that everything is added to the (class)path. I've > been wondering if having separate arguments for the main classes and test > classes would make it possible to prevent the patch argument while chaining > classloaders. > e.g. java -jar junit.jar -DmainPath=<arg> -DtestPath=<arg> ...<moreArgs> > > in Maven terms: mainPath will contain all compile-dependencies, testPath will > contain all test-dependencies WITHOUT the compile-dependencies. > > However, is this enough to support split packages? > > Robert
