On 9/5/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: ...
> > How to define platform? Get platform information in test code? > > > Yes. It is just one line of code. For example, from Support_Exec.java > class: > boolean onUnix = File.separatorChar == '/'; Yes, it does work sometimes, but ... How to differentiate AIX, solaris, linux, unix, windows and etc...
Do we really need in it? At present time tests were designed for win/unix only. In any case, I don't against the groups but if we define 'general' groups set it should include 'regression' group too.
If there's a public API or can be retrieved from system property, it may work.
The public API does not specify exact names for platforms (java is platform independent :) ) so these ways are equals (but for impl tests it will works fine). thanks, Vladimir
thanks, Vladimir > > 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. > > > > > > > > > > > > Yes. We should figure out all possible groups. And it can be > > > consolidated > > > > during applying TestNG. > > > > > > > > > Agree. > > > thanks, Vladimir > > > > > > 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. > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > -- > > Andrew Zhang > > China Software Development Lab, IBM > > > > > > -- Andrew Zhang China Software Development Lab, IBM
