-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unit test - split "AND"-ed conditionals into separate asserts #596
Comments
Added milestone, targeted for this round for unit test consistency. |
Now that the UT macros for OSAL have been accepted I can take a look at using that model for CFE as well (I have a crack at sb_UT.c but I like the OSAL macros even more so I will revisit.) |
In order to cross reference/validate that the test cases are covering the documented functions, need to do a scrub of all "Report" outputs and make them use the proper macros that include full context info. |
Scrub through all UT reporting calls in es_UT.c and replace with preferred macro where possible. - All calls to check status/return code are replaced with macro that logs all arguments and return value - All calls that involved multiple conditions AND'ed together are replaced with individual asserts on each condition.
Scrub through all UT reporting calls in es_UT.c and replace with preferred macro where possible. - All calls to check status/return code are replaced with macro that logs all arguments and return value - All calls that involved multiple conditions AND'ed together are replaced with individual asserts on each condition.
Scrub through all UT reporting calls in es_UT.c and replace with preferred macro where possible. - All calls to check status/return code are replaced with macro that logs all arguments and return value - All calls that involved multiple conditions AND'ed together are replaced with individual asserts on each condition.
Update ES coverage test to use preferred macros. Adds dedicated assert macros for checking fixed-length string buffers, and for checking memory offsets. Also adds an improved implemention of the syslog/printf check which filters out newlines (keeps log more parseable).
Update EVS coverage test to use preferred macros
Update SB coverage test to use preferred macros. Adds a dedicated assert macro for checking SB MsgId values.
Update MSG coverage test to use preferred macros
Update SBR coverage test to use preferred macros
Update TBL coverage test to use preferred macros
Update TIME coverage test to use preferred macros
Update FS coverage test to use preferred macros.
Clean up the assert functions and macros which are no longer used after updating all coverage tests to use preferred macros.
Update ES coverage test to use preferred macros. Adds dedicated assert macros for checking fixed-length string buffers, and for checking memory offsets. Also adds an improved implemention of the syslog/printf check which filters out newlines (keeps log more parseable).
Update EVS coverage test to use preferred macros
Update SB coverage test to use preferred macros. Adds a dedicated assert macro for checking SB MsgId values.
Update MSG coverage test to use preferred macros
Update SBR coverage test to use preferred macros
Update TBL coverage test to use preferred macros
Update TIME coverage test to use preferred macros
Update FS coverage test to use preferred macros.
Clean up the assert functions and macros which are no longer used after updating all coverage tests to use preferred macros.
Clean up the assert functions and macros which are no longer used after updating all coverage tests to use preferred macros.
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:
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
&&
conditions into separate asserts. This would at least let the developer know which one is actually the fault.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.
The text was updated successfully, but these errors were encountered: