George Harley wrote:
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.
Sorry, I meant that all tests intended to run on the classpath should be
compiled to bin/test.
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.
...likewise, I meant that tests intended for the bootclasspath should be
compiled to something like a bin/test-internal
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]
