|Subject:||Re: ChangeLog encoding; testsuite file/s|
|Date:||Mon, 17 Jan 2022 19:42:11 +0100|
The is a testsuite in every package which, in my opinion is unnecessarily so
big. I refer here to `test*(.lz)' files. They don't have to be this big to show
and test features they represent.
Yes, they have to be that big, or even bigger. In lziprecover 1.16 a bug in
--split was not detected by 'make check' because the test file was too
small. In general a file needs to be larger than the input buffer to test
that there are no problems when reaching the end of the buffer.
Shipping large test files in a separate package won't work; nobody will
download it to run the additional tests.
BTW, the development version of gzip generates and compresses a file of 4
GiB of uncompressed size to test the new functionality of --list because it
is the smallest file able to test it.
Looks like you have answered yourself to this - they can be generated, as in gzip example you gave. They can also be downloaded from online repository, something like in Slackbuild scripts. This was you can also prepare better, more elaborate test, pack it with zip or tar and download that complex part when necessary. I can very that 95% of people don't do test on "regular basis" (with every time compilation).
I will prepare script later, when have more time.
|[Prev in Thread]||Current Thread||[Next in Thread]|