> [SNIP]
>
> IMHO, this relates to "stress tests and load tests" only. This means that we
> shouldn't put such kind of tests in a 'regular test suite'. The 'regular
> test suite' is used to verify regressions only. Returning back to a test's
> size, I think it is up to developer - we can only recommend not to test all
> functionality in one test case and split independent parts into a number of
> test case. But IMHO we can not fully avoid creating 'redundant code', such
> as, "Assert 1:", "Assert 2: ....". For example, if there is a constructor
> with several parameters and get-methods to return provided parameters then I
> wouldn't create 3 tests instead of the next one:
>
> public void test_Ctor() {
> Ctor c = new Ctor(param1, param2, param3);
>
> assertEquals("Assert 1", param1, c.getParam1());
> assertEquals("Assert 2", param2, c.getParam3());
> assertEquals("Assert 3", param3, c.getParam2());
> }
Hi folks,
I actully agree with Stepan. It all depends on the edvelopers since
the people do what is convenient and generally makes sense. However
from the tester's point of view (my one, you can guess :) ) when you
check several assertions in the test (like in
org.apache.harmony.tests.java.util.jar.test_putLjava_lang_ObjectLjava_lang_Object)
if one assertion is broken you won't see what's going on with others
unless you get this one fixed.
BTW do we have any way to include stress/reliability tests in the project?
Thanks,
Alex Orlov.
Intel Middleware Products Division
>
> Thanks,
> Stepan.
>
>
> Thanks a lot.
> >
> > Richard Liang wrote:
> > > Dears,
> > >
> > > As I cannot find similar pages about testing convention, I just create
> > > one with my rough ideas
> > > http://wiki.apache.org/harmony/Testing_Convention, so that we can
> > > document our decision timely & clearly.
> > >
> > > Geir Magnusson Jr wrote:
> > >>
> > >>
> > >> Leo Simons wrote:
> > >>> Gentlemen!
> > >>>
> > >>> On Mon, Mar 27, 2006 at 11:07:51AM +0200, mr A wrote:
> > >>>> On Monday 27 March 2006 10:14, mr B wrote:
> > >>>>> On 3/27/06, mr C wrote:
> > >>>>> [SNIP]
> > >>>>>> [SNIP]
> > >>>>>>> [SNIP]
> > >>>>>>>> On 1/1/2006, mr D wrote:
> > >>>>>>>>>>>>>>>>>>> [SNIP]
> > >>>>> Hmmm... Lemme support [SNIP]
> > >>>> Now let me support [SNIP].
> > >>>
> > >>> The ASF front page says
> > >>>
> > >>> (...) "The Apache projects are characterized by a collaborative,
> > >>> consensus
> > >>> based development process, " (...)
> > >>>
> > >>> That's not just some boilerplate. Consensus is a useful thing.
> > >>>
> > >>> "How should we organize our tests?" has now been the subject of
> > >>> debate for
> > >>> *months* around here, and every now and then much of the same
> > >>> discussion is
> > >>> rehashed.
> > >>
> > >> And we're making progress. IMO, it really helped my thinking to
> > >> distinguish formally between the implementation tests and the spec
> > >> tests, because that *completely* helped me come to terms with the
> > >> whole o.a.h.test.* issue.
> > >>
> > >> I now clearly see where o.a.h.test.*.HashMapTest fits, and where
> > >> java.util.HashMapTest fits.
> > >>
> > >> I don't think our issues were that obvious before, at least to me.
> > >> Now, I see clearly.
> > >>
> > >>>
> > >>> I think it would be more productive to look for things to agree on
> > >>> (such as,
> > >>> "we don't know, but we can find out", or "we have different ideas on
> > >>> that,
> > >>> but there's room for both", or "this way of doing things is not the
> > >>> best one
> > >>> but the stuff is still useful so let's thank the guy for his work
> > >>> anyway")
> > >>> than to keep delving deeper and deeper into these kinds of
> > >>> disagreements.
> > >>>
> > >>> Of course, the ASF front page doesn't say that "apache projects are
> > >>> characterized by a *productive* development process". Its just my
> > >>> feeling that
> > >>> for a system as big as harmony we need to be *very* productive.
> > >>
> > >> You don't think we're making progress through these discussions?
> > >>
> > >>>
> > >>> Think about it. Is your time better spent convincing lots of other
> > >>> people to do
> > >>> their testing differently, or is it better spent writing better tests?
> > >>
> > >> The issue isn't about convincing someone to do it differently, but
> > >> understanding the full scope of problems, that we need to embrace
> > >> both approaches, because they are apples and oranges, and we need
> > >> both apples and oranges. They aren't exclusionary.
> > >>
> > >> geir
> > >>
> > >
> > >
> >
> >
> > --
> > Richard Liang
> > China Software Development Lab, IBM
> >
> >
> >
>
>
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
