On 9/11/06, Richard Liang <[EMAIL PROTECTED]> wrote:
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.
Either is ok. One is more descriptive while the other is more convenient. If we have no problem to write test.xml with default group(@Test), then I prefer this option a little. Thanks! 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]
-- Andrew Zhang China Software Development Lab, IBM
