2126ca8a5f
Recipe in /tests rebuild everything from source for each target. zstd is still a "small" project, so it's not prohibitive, yet, rebuilding same files over and over represents substantial redundant work. This patch replaces *.c files from /lib by their corresponding *.o files. They cannot be compiled and stored directly within /lib, since /tests triggers additional debug capabilities unwelcome in release binary. So the resulting *.o are stored directly within /tests. It turns out, it's difficult to find several target using *exactly* the same rules. Using only the default rules (debug enabled, multi-threading disabled, no legacy) a surprisingly small amount of targets share their work. It's because, in many cases there are additional modifications requested : some targets are 32-bits, some enable multi-threading, some enable legacy support, some disable asserts, some want different kind of sanitizer, etc. I created 2 sets of object files : with and without multithreading. Several targets share their work, saving compilation time when running `make all`. Also, obviously, when modifying one source file, only this one needs rebuilding. For targets requiring some different setting, build from source *.c remain the rule. The new rules have been tested within `-j` parallel compilation, and work fine with it. |
||
|---|---|---|
| .. | ||
| files | ||
| fuzz | ||
| gzip | ||
| .gitignore | ||
| datagencli.c | ||
| decodecorpus.c | ||
| fullbench.c | ||
| fuzzer.c | ||
| invalidDictionaries.c | ||
| legacy.c | ||
| longmatch.c | ||
| Makefile | ||
| paramgrill.c | ||
| playTests.sh | ||
| poolTests.c | ||
| README.md | ||
| roundTripCrash.c | ||
| seqgen.c | ||
| seqgen.h | ||
| symbols.c | ||
| test-zstd-speed.py | ||
| test-zstd-versions.py | ||
| zbufftest.c | ||
| zstreamtest.c | ||
Programs and scripts for automated testing of Zstandard
This directory contains the following programs and scripts:
datagen: Synthetic and parametrable data generator, for testsfullbench: Precisely measure speed for each zstd inner functionsfuzzer: Test tool, to check zstd integrity on target platformparamgrill: parameter tester for zstdtest-zstd-speed.py: script for testing zstd speed difference between commitstest-zstd-versions.py: compatibility test between zstd versions stored on Github (v0.1+)zbufftest: Test tool to check ZBUFF (a buffered streaming API) integrityzstreamtest: Fuzzer test tool for zstd streaming APIlegacy: Test tool to test decoding of legacy zstd framesdecodecorpus: Tool to generate valid Zstandard frames, for verifying decoder implementations
test-zstd-versions.py - script for testing zstd interoperability between versions
This script creates versionsTest directory to which zstd repository is cloned.
Then all tagged (released) versions of zstd are compiled.
In the following step interoperability between zstd versions is checked.
test-zstd-speed.py - script for testing zstd speed difference between commits
This script creates speedTest directory to which zstd repository is cloned.
Then it compiles all branches of zstd and performs a speed benchmark for a given list of files (the testFileNames parameter).
After sleepTime (an optional parameter, default 300 seconds) seconds the script checks repository for new commits.
If a new commit is found it is compiled and a speed benchmark for this commit is performed.
The results of the speed benchmark are compared to the previous results.
If compression or decompression speed for one of zstd levels is lower than lowerLimit (an optional parameter, default 0.98) the speed benchmark is restarted.
If second results are also lower than lowerLimit the warning e-mail is send to recipients from the list (the emails parameter).
Additional remarks:
- To be sure that speed results are accurate the script should be run on a "stable" target system with no other jobs running in parallel
- Using the script with virtual machines can lead to large variations of speed results
- The speed benchmark is not performed until computers' load average is lower than
maxLoadAvg(an optional parameter, default 0.75) - The script sends e-mails using
mutt; ifmuttis not available it sends e-mails without attachments usingmail; if both are not available it only prints a warning
The example usage with two test files, one e-mail address, and with an additional message:
./test-zstd-speed.py "silesia.tar calgary.tar" "email@gmail.com" --message "tested on my laptop" --sleepTime 60
To run the script in background please use:
nohup ./test-zstd-speed.py testFileNames emails &
The full list of parameters:
positional arguments:
testFileNames file names list for speed benchmark
emails list of e-mail addresses to send warnings
optional arguments:
-h, --help show this help message and exit
--message MESSAGE attach an additional message to e-mail
--lowerLimit LOWERLIMIT
send email if speed is lower than given limit
--maxLoadAvg MAXLOADAVG
maximum load average to start testing
--lastCLevel LASTCLEVEL
last compression level for testing
--sleepTime SLEEPTIME
frequency of repository checking in seconds
decodecorpus - tool to generate Zstandard frames for decoder testing
Command line tool to generate test .zst files.
This tool will generate .zst files with checksums, as well as optionally output the corresponding correct uncompressed data for extra verfication.
Example:
./decodecorpus -ptestfiles -otestfiles -n10000 -s5
will generate 10,000 sample .zst files using a seed of 5 in the testfiles directory,
with the zstd checksum field set,
as well as the 10,000 original files for more detailed comparison of decompression results.
./decodecorpus -t -T1mn
will choose a random seed, and for 1 minute, generate random test frames and ensure that the zstd library correctly decompresses them in both simple and streaming modes.