You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2008/01/27 11:04:39 UTC

Jackrabbit test suite (Was: Smaller and Quicker Releases)

Hi,

On Jan 27, 2008 10:46 AM, Thomas Mueller <th...@gmail.com> wrote:
> > That does _not_ mean there shouldn't be more test coverage ;-)
>
> Yes, but we need to agree we want that. We need to define the target,
> and the process.

I don't think anyone would disagree with contributions towards
improving the Jackrabbit test suite.

It's a different matter if we want to raise the bar for incoming
contributions or releases to include and pass extensive test suites.
At least we need to carefully consider such changes. Having some
concrete proposals would help.

We already have a reasonably solid and tested codebase to work on, and
personally I'm more a fan of continuous improvement based on incoming
bug reports than of "Big Testing Up Front" (compare to [1]). A test
suite is essentially an operational version of a functional
requirements document, and comes with the same drawbacks.

Just like I really wouldn't mind having a real design document for
Jackrabbit, I'd be happy to see more extensive test coverage. But I
don't believe in those things religiously and I wouldn't want to stop
feature or bug fixing work because of documentation or testing
requirements. I understand that this may well be a bad policy, and I'd
be happy to debate it and be proven wrong if possible.

[1] http://en.wikipedia.org/wiki/Big_Design_Up_Front

BR,

Jukka Zitting

Re: Jackrabbit test suite (Was: Smaller and Quicker Releases)

Posted by Thomas Mueller <th...@gmail.com>.
Hi,

> raise the bar for incoming contributions or releases to include and pass extensive test suites.

For features marked 'experimental' an extensive test suite is not
required. But features marked stable should have extensive tests, also
to reduce the risk of changes and bugfixes.

> concrete proposals

Let's say, features marked stable need to have 80% code coverage and
90% functional test coverage.

I'm absolutely not proposing Big Design Up Front and the waterfall
model. What I'm proposing is Test Driven Development
(http://en.wikipedia.org/wiki/Test-driven_development).

Regards,
Thomas