In which case, your tests need to be from code *outside* the modules, right? So logically, since code that uses a module from the outside must be in other packages, it makes the most sense for your tests to be, as well.
> On Nov 25, 2016, at 1:56 PM, [email protected] wrote: > > Hi Russel, > part of the code i test use Layers and annotations on Modules, it just > doesn't work with in a non module environment :( > > regards, > Rémi > > De: "Russell Gold" <[email protected]> > À: "jigsaw-dev" <[email protected]> > Cc: "Robert Scholte" <[email protected]>, "Sander Mak" > <[email protected]>, "Remi Forax" <[email protected]> > Envoyé: Vendredi 25 Novembre 2016 17:15:44 > Objet: Re: modules and tests > 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 <[email protected] > <mailto:[email protected]>> wrote: > > On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax <[email protected] > <mailto:[email protected]>> 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 > >
