-
Notifications
You must be signed in to change notification settings - Fork 236
Description
Is your feature request related to a problem? Please describe.
Debugging unit tests can be very difficult, frustrating, and time consuming. One major part of the problem which makes them very debugging-unfriendly is something like the following:
UT_Report(__FILE__, __LINE__,
UT_EventIsInHistory(CFE_ES_PCR_ERR2_EID) &&
CFE_ES_Global.AppTable[Id].ControlReq.AppTimer == 0 &&
CFE_ES_Global.AppTable[Id].ControlReq.AppControlRequest == CFE_ES_RunStatus_SYS_DELETE,
"CFE_ES_ScanAppTable",
"Waiting; process control request");
The problem with this type of construct is that there are 3 separate tests being combined into one single assert. When it fails, it is not possible to see which of the three conditions are evaluating false. Many of them call functions within the test case, too, which further obfuscate what the actual return value was. The only way to test this is run it in a debugger, break at the start of the test, then set a breakpoint inside e.g. UT_EventIsInHistory to see what it returned.
Describe the solution you'd like
- At a minimum - split the
&&conditions into separate asserts. This would at least let the developer know which one is actually the fault. - Nice to have - employ the macros similar to what @CDKnightNASA added in Fix #397, Remove old unit test example, add README.md, further macro cleanup osal#405, which show the values tested in the log, not simply just a pass/fail.
Describe alternatives you've considered
Continue struggling to figure out what actually went wrong every time a UT failure comes up.
Requester Info
Joseph Hickey, Vantage Systems, Inc.