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, fo...@univ-mlv.fr 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" <russell.g...@oracle.com> > À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Cc: "Robert Scholte" <rfscho...@apache.org>, "Sander Mak" > <sander....@luminis.eu>, "Remi Forax" <fo...@univ-mlv.fr> > 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 <rfscho...@apache.org > <mailto:rfscho...@apache.org>> wrote: > > On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax <fo...@univ-mlv.fr > <mailto: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 > >
