Search…
⌃K

Torture

When curl is built debug enabled, it offers a special kind of testing. The tests we call torture tests. Do not worry, it is not quite as grim as it may sound.
They verify that libcurl and curl exit paths work without any crash or memory leak happening,
The torture tests work like this:
  • run the single test as-is first
  • count the number of invoked fallible functions
  • rerun the test once for every falling function call
  • make each fallible function call return error, one by one
  • verify that there is no leak or crash
  • continue until all fallible functions have been made to fail
This way of testing can take a seriously long time. I advise you to switch off valgrind when trying this out.

Rerun a specific failure

If a single test fails, runtests.pl will identify exactly which "round" that triggered the problem and by using the -t as shown, you can run a command line that when invoked only fails that particular fallible function.

Shallow

To make this way of testing a little more practical, the test suite also provides a --shallow option. This lets the user set a maximum number of fallible functions to fail per test case. If there are more invokes to fail than is set with this value, the script will randomly select which ones to fail.
As a special feature, as randomizing things in tests can be uncomfortable, the script will use a random seed based on year + month, so it will remain the same for each calendar month. Convenient, as if you rerun the same test with the same --shallow value it will run the same random tests.
You can force a different seed with runtests' --seed option.
Last modified 5mo ago