2006/4/28, Anton Avtamonov <[EMAIL PROTECTED]>: > On 4/28/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > 2006/4/27, Anton Avtamonov <[EMAIL PROTECTED]>: > > > On 4/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > I say leave them mixed. We are no more likely to want to run > > > > serialization tests separately than we are locking tests etc. and trying > > > > to layout the tests on disk to represent all the different metadata > > > > about each test case is not going to work. > > > > > > +1. usually we have test layout like: one class - one TestCase. I > > > > Sometimes we need different setUp and tearDown operations > > for different tests against the same class. This is best to be handled as > > multiple TestCases (or test classes in other words as TestCase can be > > ambiguous) > > That's true. It happens quite often and has no correlation with some > particular type of tests (like serialization testing). When you need > to cover 50 methods of some class for instance, you can hardly expect > that all the preparation required for one of them is really needed for > others. I don't think that is a good reason to create separated test > cases. I'd prefer to use the most essential and common instantiations > in setUp() and provide further customization in each particular test.
Some days ago I posted statistics about ~1% of tests that run 80% of time. Most of these tests do exactly what you describe here - in the test methods they do what is supposed to be done in setUp Thanks, Mikhail > I expected that is common approach... > > IMHO the reason to introduce additinal TestCases can be when one need > to test something really 'separated'. Something, which requires > absolutely different setUp() and may even override runBare() (to run > tests in the another thread, etc). > For instance, it may be nesessary for multi-threading testing. > > Wishes, > -- > Anton Avtamonov, > 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] > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
