tests data in CVS

[Stephane Bailliez <st...@haht.com>]

Rough questions:

is there a point for having so huge testing data for BZip2 tests ?

- I was forced to shrink the size to something a bit more reasonable as the
tests under coverage were taking about 10 minutes for BUnzip2 and I killed
BZip2 test after 30 mins.

- I will do the same for JProbe Coverage loader tests as the tests I'm doing
is also some kind of performance tests and is taking about 5 mins.

All this is in running in classic mode (it's actually worse when running
with Hotspot)

--
Stephane Bailliez
Software Engineer, Paris - France
HAHT - http://www.haht.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: tests data in CVS

[Magesh Umasankar <um...@apache.org>]

From: "Stephane Bailliez" <st...@haht.com>

>
> is there a point for having so huge testing data for BZip2 tests ?
>

Yes.  When you compress a file, we want to force
bzip2 to compress it using *multiple* blocks.  So,
we need a file large enough such that it doesn't
get compressed into a single block.

We started using the new file because we found
a bug in our implementation of BZip2 that was
generating invalid bz2 files is the number
of blocks was greater than 1.

> - I was forced to shrink the size to something a bit more reasonable as
the
> tests under coverage were taking about 10 minutes for BUnzip2 and I killed
> BZip2 test after 30 mins.

Test with native bzip2 in verbose mode to see
how many blocks are there in your new file.
If it is more than one, then it is good
enough.

> Stephane Bailliez

Cheers,
Magesh




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>