Project

General

Profile

Task #2975

Updated by Juliana Fajardini Reichow about 1 year ago

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 very 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 can is 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. https://github.com/OISF/suricata/blob/master/src/detect-mark.c#L259. 
 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.

Back