harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [classlib] Testing
Date Wed, 03 May 2006 09:13:30 GMT
2006/5/3, Tim Ellison <t.p.ellison@gmail.com>:
> 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 (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message