On 23/03/2016 14:42, Stephen Colebourne wrote:
:
I don't particularly care what the mechanism is for this, but at the
requirements level:
- there are two modules - main and test
- each has its own source tree
- each has its own dependencies
- each is released separately
- each could be hosted on a central repo
- the test module needs to be able to contain the same packages as the
main module
- the test module needs to be able to invoke package-scoped code in
the same package in the main module
To clarify further consider 4 modules, A, B, A-test and B-test where B
depends on A. Module A-test may have a method foo() that uses package
scope to access something in A. Module B-test will depend on A-test
and rely on foo() to get access to that internal object.
To your list, I would add the ability to make use of testing frameworks
like TestNG and JUnit.
In any case, and as things currently stand, you've got most of the
above. One differences is that the tests are not a separate module, they
are instead compiled and run in a way that patches the main module. The
second difference is that they don't have their own module declaration,
instead the compilation or run augments the dependences with any
additional dependences that the tests have. As I said, if they tools
makes it easy then I don't think it's too bad.
(Note that I view the thread discussion of
references to test classes on the classpath as another hack.
Packages can't be split between modules and classpath so there is no
support for that.
-Alan
