2006/5/3, Tim Ellison <[EMAIL PROTECTED]>:
Mikhail Loenko wrote:
> Did everybody agree to:
I think so -- I just need to clarify some terminology I think...
> 1. Tests are separated on directory level by 'intention'
I agree where the intention is broad (i.e. functional tests vs.
performance tests vs. stress tests) but I'm not convinced that we need
to separate to a precise 'intent', at least I've never been in a
position where I've wished that my my serialization tests are separate
from my cloning tests or whatever.
I did not mean that we separate "all tests against method 'clone'" from
"all tests against constructors" into different dirs :)
The problem I see is that trying to represent too many different
classifications in a test's directory/file name leads to complex naming
rules and eventually ambiguity or duplication when tests cross those
classification groups. So I'd like to keep it simple.
+1
I do agree that we should separate tests that we expect to run on any
compliant Java implementation from those that are Harmony specific.
> src/tests/
> |
> + impl/
> |
> + compliant/
Just a minor nit -- we may choose to call these 'api' tests just to be
very clear that we are not defining or modifying the meaning of
'compliant' (which is the role of the JCK).
OK, I see
> + etc [might be stress, exotic, or something else]/
We would create new directories as we need them, right?
> \ resources/ -- as they are
>
> Note: inside 'intention' directory they might be further separated e.g
> by platform
In fact, we should allow for some autonomy within a module too. There
will be a different balance between the types of tests that are required
for, say, LUNI and those for RMI that mean the structure may not suit
every module equally well.
In general I'm ok with autonomy within a module. Though more specific
example about luni would be helpful.
> 2. 'Bootclasspath' tests are in the same package as implementation
Yes -- where do these appear in the layout?
Depending on what are these tests. Most likely they will be in 'impl'
as we likely will not have many 'bootclasspath' API tests
> 3. 'classpath' tests against 'public packages' go to
> org.apache.harmony.module.tests.<public package name>
>
> note: public package name is not necessary in the java.* or javax.*
> example: org.ietf.jgss
Yes.
> 4. 'classpath' tests against org.apache.harmony.module.<rest of the name>
> classes go to
> org.apache.harmony.module.tests.<rest of the name>
Yes.
Thanks for working through this Mikhail -- I feel that we are converging
on a good solution.
Would you be able to put together a (proposed) document describing this
on the classlib website?
Ok, I'll put this on the website
Thanks,
Mikhail
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
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]
