On 9/11/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
Hi all,
> One more note (seems it already was said sorry if I repeat): the test
> without any marks should be run in all configurations (i.e. we have
> 'default' group but declaration of this group may be missed).
I'd like to point your attention on the previous discussion about
"default groups" :
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
I am still for using "os.any" since it is more self-descriptive and
the build script will be simpler with "os.any". It will be nice to
hear more arguments for using defaults because it seems the arguments
that were gathered in that old thread hasn't been taken into account
by participants of this thread.
I have not any strong objection about "os.any". And actually I had
ever proposed to define the "default" group because we could not
include tests with annotation @Test which belong to no groups. Now it
isn't a problem as we already have a solution for them. To facilitate
writing test cases, we annotate the unit tests which are designed to
pass on all platforms (os + arch) with @Test.
If we use "os.any" and "arch.any", then the default annotation would
be @Test(groups={"os.any", "arch.any"})
Could any other give more comments? Thanks a lot.
Best regards,
Richard
Thanks,
2006/9/5, Vladimir Ivanov <[EMAIL PROTECTED]>:
> One more note (seems it already was said sorry if I repeat): the test
> without any marks should be run in all configurations (i.e. we have
> 'default' group but declaration of this group may be missed).
>
> thanks, Vladimir
>
>
> On 9/5/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:
> >
> > OK, let's return back to the usage model.
> > If I understood it correctly, before the commit of any changes each
> > developer run *all* tests (at least all which we have now) on all available
> > to him platforms. In this context seems we don't need in any 'level' group
> > (while 'stress' tests require reasonable time to pass).
> > Seems, that "platform" group also can be deleted (at present time we have
> > <10 platform-dependent tests and this amount should not increase
> > dramatically so the platform-detection can be included to the each such
> > test).
> > Also "cpu" groups can be deleted (while we have not cpu-dependent test).
> > At the end we need only "state" groups to support test exclusion on the
> > 'one-element' level (while we have unresolved entries in the current exclude
> > list).
> >
> > So, after small update of unit (aka integration, aka regression etc) tests
> > and resolution of all entries in the exclude list we don't need any groups
> > and pure JUnit covers all our needs :)
> >
> > On the other side, if we define some groups it will nice to define *all*
> > reasonable groups at the begin of the process.
> >
> > thanks, Vladimir
> >
> > By the way, our regression tests are 'classic' regression tests that
> > demonstrate some issues which were not resolved by initial code. But it
> > provides less coverage than 'regression tests' + unit tests, of cause.
> >
> > On 9/5/06, Richard Liang <[EMAIL PROTECTED] > wrote:
> > >
> > > On 9/5/06, Alex Blewitt < [EMAIL PROTECTED]> wrote:
> > > > On 04/09/06, Richard Liang <[EMAIL PROTECTED]> wrote:
> > > > > On 9/4/06, Alex Blewitt <[EMAIL PROTECTED] > wrote:
> > > > > >
> > > > > > If you've got fast and slow tests, then have a group for fast and
> > > slow
> > > > > > tests. Then you can choose to just run the fast tests, and any
> > > > > > automated build system can handle running the slow tests.
> > > > >
> > > > > IMHO, "fast or slow" may not be the key point. The question is
> > > whether we
> > > > > have any requirements to run only the regression tests.
> > > >
> > > > No, probably not the key point, but (a) groups don't have to be
> > > > mutually exclusive (so you can decorate it with whatever groups you
> > > > want)
> > >
> > > I agree. For example, os.win and os.linux are not mutually exclusive.
> > >
> > > Thanks a lot.
> > >
> > > and (b) it might be useful for an automated build system to run
> > > > fast tests first, followed by slow (or non-fast) tests.
> > >
> > > That makes sense through we have not clear requirement currently.
> > >
> > > > Mind you, I don't know what's going to happen with an automated
> > > test'n'build
> > > > system; so it might not make sense to do it at this point.
> > >
> > > Really? ;-) We could also discuss whether it's feasible to move to
> > > TestNG. As you may know, there are already several threads about
> > > TestNG & JUnit. Here I just review the open questions one by one so
> > > that we have sufficient preparation.
> > >
> > >
> > >
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
> > >
> > >
[2]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
> > >
> > >
[3]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
> > >
> > >
> > > Best regards,
> > > Richard
> > >
> > > >
> > > > Alex.
> > > >
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
