Fix #1124, add generic asserts from CFE coverage testing

[jphickey]

Describe the contribution
Migrates some of the assert extensions that were added for CFE coverage testing to the UtAssert level, so they can be used
in a wider scope of tests, not just CFE coverage.

The existing macros (e.g. UtAssert_INT32_EQ) are updated to use the same facility.

All macros are now also a single line and return the boolean pass/fail status, which was a useful feature of the CFE macros.

Fixes #1124

Testing performed
Build and run all tests (functional + coverage) and confirm results are normal.

Expected behavior changes
No operational change to existing asserts, but formatting of some logs may change a little bit, so it may affect some scripts that are looking for very specific message (although it did not affect any of my log parsing scripts).

System(s) tested on
Ubuntu

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

I'm marking as "draft" for now - there is just one minor issue, and I'd like to solicit opinions/ideas from the dev team.

When migrating the macros from CFE and making generic,, I dropped the "CFE" prefix, so CFE_UtAssert_TRUE and CFE_UtAssert_FALSE become just UtAssert_TRUE and UtAssert_FALSE, respectively.

It all works, but, there is an existing UtAssert macros called UtAssert_True (for arbitrary expressions w/full user-defined message). So what we are left with are two macros that differ only in capitalization, which is not ideal.

If anyone has opinions on how we should resolve this while not breaking too much,, please share!

[skliper]

Good stuff, I'd be nice to see all the different ways subtests are added convert to using this common method! No rush, but great to see a common utility. I don't have any good ideas for the UtAssert_True challange... want to avoid breaking things so UtAssert_True is preferably untouchable right now (although that's the one that would probably make the most sense to change).

[zanzaben]

I don't love atmost and atleast, can they just be GreaterThanEqual and LessThanEqual instead. More blunt about what they are that way.

As for TRUE, The best thing would be to change the old True but in the short term I would say to change the name of the new TRUE to some other synonym like TRUTHFUL or NORMAL just to prevent confusion and then eventually update them both some time in the future.

[jphickey]

Thanks for the input, I kind of came to the same conclusion that these two things are basically fixed:

• Cannot change the name of the existing UtAssert_True
• Cannot leave two macros that differ only in case (that's just fundamentally mean, and probably against some coding standards)

So this leaves the only option of coming up with an alternate name for the UtAssert_TRUE macro.

I'm currently leaning toward UtAssert_BOOL_TRUE and UtAssert_BOOL_FALSE (as this follows the same pattern as UtAssert_INT32_EQ et al).

[jphickey]

Last push reflects the BOOL_TRUE/BOOL_FALSE idea, so should be generally OK now.

I'm open to renaming ATLEAST/ATMOST too, my only objection is that the macro name can get pretty long. I'm hesitant to make something as long as UtAssert_INT32_GREATERTHANOREQUAL, but I suppose we could. Do you think something like UtAssert_INT32_MINIMUM would be clearer (its shorter at least)?

[skliper]

My preference would be one of the "common" abbreviations like GT/GE/LT/LE or GTE/LTE. We use EQ so just extending that pattern.

[jphickey]

OK - last push should address the naming conventions, and does a little more cleanup (group like-type macros together, etc). Had to revise a couple times due to typical issues (clang-format, fat finger, etc), but hopefully good now.

@skliper, @zanzaben please re-review

[jphickey]

Note - in an attempt at being proactive I also added an "NEQ" (not equal) variation of the macro in this commit, although nothing uses it yet. Since the comparison type exists and the code is implemented, I figured it's worth making a macro for as well, just in case someone wants it in the future.

[astrogeco]

CCB:2021-08-04 APPROVED

• Should we output both decimal and HEX?
  • Decimal makes it easy to read but it's easier to convert when needed with an external script