Suricata

If you are interested in working on this task, please check the available subtasks. Community contributors are welcome to work on them.¶

Convert existing tests to use the FAIL/PASS API. The idea is that every step in a test is checked and that the test should not leak memory on its success path.

There are many tests, some of which have lots of duplication. Consider per test whether the test can be improved (cleaned up) further.
This is not something meant to be done in one step. A commit per source file is ok. PRs can include multiple commits.

More explanations and context:

Initially, a lot of tests were written just like any other method: there were multiple conditionals for failure (return 0) and one pass condition (return 1), e.g.:

/**
 * \test MarkTestParse01 is a test for a valid mark value
 *
 *  \retval 1 on succces
 *  \retval 0 on failure
 */
static int MarkTestParse01 (void)
{
    DetectMarkData *data;

    data = DetectMarkParse("1/1");

    if (data == NULL) {
        return 0;
    }

    DetectMarkDataFree(NULL, data);
    return 1;
}

While there was nothing wrong with this approach, we found it would be much cleaner if we used conditional macros that clearly say whether the test "fails" or "passes" on a certain condition. So, we introduced a lot of well-defined macros (see https://github.com/OISF/suricata/blob/master/src/util-unittest.h) to make the tests more legible and clear.

There are macros for almost all failing conditionals e.g., fail if something is null (FAIL_IF_NULL), fail if something
exists (>0) (FAIL_IF), etc. There are also macros PASS and PASS_IF which mean all the conditionals were met properly and the test has passed.

Your job as a part of this task is to remove the old style of tests, i.e. returning values on failure/passing
conditionals, and use this FAIL/PASS API instead. One good example could be
https://github.com/OISF/suricata/commit/3cf8b4629f2cf523c3f82604d93b8fd4a0888109:

There, all the conditionals were converted to the FAIL/PASS API in a manner that there is NO memory leak on the success path (PASS). It is OK to have memleaks on failure paths.