On 9/11/06, Alexei Zakharov 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".
This is not a good argument for using "os.any". Even more it may sound like we are going to choose "wrong tool" - why we have to add "os.any" to 99% of classlib tests? just because the harness can not do without it? 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.
As I understand "arguments in the old thread" - TestNG makes us to use " os.any" annotation otherwise we have to do a lot of tricks to run tests, right? IMO a test annotation should be used as "red flag" for developer, for example * "state.broken" - hey, i'm broken fix me please * "os.win" - i'm valid only for Windows, don't try to run me on Linux So a test's annotation should point out that the test is a special one. But if most of tests will contain a similar block of annotations then nobody will looked at them. Does this make sense? Thanks, Stepan. 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. > > > >
-- Thanks, Stepan Mishura Intel Middleware Products Division ------------------------------------------------------ Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
