Geir Magnusson Jr wrote:
George Harley wrote:
Geir Magnusson Jr wrote:
Geir Magnusson Jr wrote:
George Harley wrote:
>>
Of course, the text module has only "implementation-independent
tests that designed to be run from classpath". For modules that
have got implementation-specific tests then I suppose we could use
something like "org.apache.harmony.[module].tests.impl.[package
under test]" or
"org.apache.harmony.[module].tests.internal.[package under test]"
etc. I've got no preference.
-1
Put them in the same package as the class being tested, please, if
there is no problem being run that way.
Sorry to be so snippy. Been a long day.
Sure. No worries.
Why would we want this convoluted package name? Why wouldn't we
want to let them be in the same package as the class being tested
since it's implementation testing?
OK, point taken about the long package names that may result for
tests of org.apache.harmony.* stuff. If the class under test is an
internal type (i.e. in the org.apache.harmony.* package space) then I
am sure we can all agree on a sensible abbreviation so that the
org.apache.harmony part does not appear twice. So, for instance, if
we are testing public methods on
org.apache.harmony.security.foo.bar.MyType from the classpath then we
could have the test package be
org.apache.harmony.security.tests.foo.bar.
I am concerned that we are all agree on what we mean by
"implementation"-specific testing and "internal"-specific testing. I
know it has been confusing me a lot.
Yah - we should probably bottom out there...
If we want to run API tests that are specific to our implementation
then there is no need to have the test types in the same package name
as the class under test and no need for those tests to be on the
bootclasspath. Orthogonal to that are tests that are actually testing
the internals of a type - these are what I take to be candidates for
being in the same package and on the bootclasspath at test time.
So your suggestion is? I agree with you, but when reading the above,
I was expecting some kind of "therefore, I think we should...". it
could just be that I have no coffee this a.m.
geir
Hi,
Actually it was me who was suffering the effects of caffeine deficiency.
All rectified now :-)
Right, here is a sort of "therefore" that you correctly noticed was
missing from my previous note. It's probably more a cry for help as I
try and grasp towards simplicity.
I really think that there are only two kinds of unit test in the context
of this discussion and I think that where in they live in the file
system is key.
First, those that are testing public/API methods (both Java API and our
implementation-specific org.apache.harmony.* API) and do not need to be
run on the bootclasspath. For tests of Java API types, our test classes
are in packages called o.a.h.<module>.tests.<package under test>. Those
tests that are dealing with API methods of implementation-specific types
(o.a.h.*) can be in test packages that are something like
o.a.h.<module>.tests.<appropriate package fragment minus any o.a.h
duplication. On the file system all of these API tests can live under
<module>/src/test/java and be built to a bin location such as bin/main
that can be added as a classpath element in our test scripts.
Next, we have "internal" tests that are intended to access non-public
properties of a type irrespective of whether it is a public API type or
an implementation-specific type. These tests are in the same package as
the type under test and are intended to run on the bootclasspath. They
can live under a separate source folder (e.g.
<module>/src/test/java-internal or any other of Paulex's suggestions)
and get built to a separate output location (e.g. bin/main-internal)
that gets added to the bootclasspath. I like using the "-internal"
suffix since it makes it clear that the code under those locations has
been written explicitly to reach into the internals of a type.
Of course the merits of having tests in the same package as the thing
under test is another story for another thread but it seems pretty
obvious that a lot of folks go for it so I'll respect that.
OK, my coffee cup is empty now.
Best regards,
George
Best regards,
George
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]