* Philip Martin (philip@codematters.co.uk) wrote:
> Eric Dorland <eric.dorland@mail.mcgill.ca> writes:
>
> > > >raised. It's kind of a big patch since the test case had to be *big* :)
> > >
> > > * Look at libsvn_delta/random-test.c. We generate random bytes there
> > > and do provide a way to reproduce the test. Don't, and I mean do
> > > *not*, hard-code "random" bytes in the test, because then you're
> > > not testing on random data, you're testing on hard-coded data.
> >
> > Well I could feed random as a test, but I don't think it's really a
> > worthwhile test. I just wanted a test that was big enough that it
> > couldn't fit into a single buffer read, just to exercise that code
> > path. I don't think a random test really buys us anything other than
> > testing zlib, which has probably been well tested enough at this point :)
>
> I agree, we just want to test the Subversion code. However, rather
> than just hardcoding a chunk of data, I would use a simple algorithm
> to generate some bytes. It doesn't really matter what you use, a
> simple 0, 1, 2, ..., 253, 254, 255, 245, 253, ... 3, 2, 1, 0 repeated
> would probably do, or how about 256 bytes incrementing in steps of 1,
> 256 bytes incrementing in steps of 3, 256 bytes incrementing in steps
> of 5, ...
Ok, how is this better than just the hardcoded data? If the data I
generate the data in too regular a fashion, it's going to compress too
well and defeat the purpose of the test.
> However you do it, the algorithm should generate an amount of data
> based on the value of ZBUFFER_SIZE. Is ZBUFFER_SIZE something to do
> with the uncompressed data, or the compressed data?
It relates to the compressed data. It's the amount of compressed data
a read will pull in at a time, whenever a read is done on a compressed
stream. I tested the hardcoded data so I know it compresses to
something larger than ZBUFFER_SIZE (4096), which was what we wanted to
test.
> Include some null bytes in the uncompressed data to test that the
> Subversion code doesn't stop when it encounters such a byte.
Good idea, I'll do that.
--
Eric Dorland <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+
G e h! r- y+
------END GEEK CODE BLOCK------
- application/pgp-signature attachment: stored
Received on Mon Mar 31 01:51:11 2003