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, ...
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?
Include some null bytes in the uncompressed data to test that the
Subversion code doesn't stop when it encounters such a byte.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 30 13:54:17 2003