-
Notifications
You must be signed in to change notification settings - Fork 236
Description
Is your feature request related to a problem? Please describe.
The typical method of using UtAssert_INT32_EQ to validate the result of a CFE call will both invoke the function and check the result in a single macro. However, this requires advance knowledge of what the result is supposed to be, before the call is made.
In some functional test circumstances, particularly where the test is not being run in a clean/isolated environment, it may not always be feasible to predict the "correct" return code from an API call before it is made. For instance, there may be cases where a set of return values are acceptable, or the correct value depends on another aspect of system state that isn't known beforehand.
A test case may handle this currently by using a stack variable, for instance:
CFE_Status_t Status;
Status = CFE_SB_CreatePipe(&Pipe, ...);
<check other system state....determine that result should have been SUCCESS>
UtAssert_INT32_EQ(Status, CFE_SUCCESS);
While this works, the test log entry will only show the check for Status == CFE_SUCCESS, it will not show the full function call that was tested here (CFE_SB_CreatePipe(&Pipe, ...)). To make the logs most useful, this should show the full function call that was made, and that it was CFE_SUCCESS (the fact that the assertion was retroactive doesn't really matter).
Of course this can be done with the free-form UtAssert_True macro, but that requires the programmer to repeat the text of the function call, and is subject to getting stale/incorrect or cut/paste errors as any "repeated" info always is.
Describe the solution you'd like
Implement CFE UtAssert macros that decouple the function call from the expected return status value, so the test case can call the function and then retroactively/separately determine what the correct result should have been.
The CFE UtAssert library can temporarily hold the status in a temp variable. This makes it simpler for the programmer to use, avoids issues with repeating the info, keeping things honest. The use pattern would be:
/* call CFE_SB_CreatePipe() but do not actually assert specific status immediately */
CFE_UtAssert_STATUS_STORE(CFE_SB_CreatePipe(&PipeId[NumPipes], 10, PipeName));
<check other system state....determine that result should have been SUCCESS>
CFE_UtAssert_STATUS_WAS(CFE_SUCCESS);
With this pattern, the assert library holds the full text of the function between the store and assert, so it can be logged in the same format as UtAssert_INT32_EQ does, and not require the programmer to repeat it, or jump through other hoops to make sure that the call gets into the test log as it should.
Describe alternatives you've considered
Leave as is, but this imposes burdens on the programmer for corner cases (by repeating info unnecessarily, and having to be explicitly concerned with writing it to the test log to make the test count) and/or makes tests more fragile by repeating info (after cut/paste/move the text of the copy can get out of sync with the real call). Having a false/incorrect log is often worse than not having a log at all.
Requester Info
Joseph Hickey, Vantage Systems, Inc.