modules and tests
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Nov 25 18:56:06 UTC 2016
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.gold at oracle.com>
> À: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Cc: "Robert Scholte" <rfscholte at apache.org>, "Sander Mak"
> <sander.mak at luminis.eu>, "Remi Forax" <forax at 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 < rfscholte at apache.org > wrote:
>> On Thu, 24 Nov 2016 15:39:19 +0100, Remi Forax < forax at 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
More information about the jigsaw-dev
mailing list