Skip to content

Latest commit

 

History

History
40 lines (29 loc) · 1.62 KB

torture.md

File metadata and controls

40 lines (29 loc) · 1.62 KB

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 identifies 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 randomly selects which ones to fail.

As a special feature, as randomizing things in tests can be uncomfortable, the script uses a random seed based on year + month, so it remains the same for each calendar month. Convenient, as if you rerun the same test with the same --shallow value it runs the same random tests.

You can force a different seed with runtests' --seed option.