Consolidate around single base set of unit test APIs (can extend, but should be based on a consistent set)

[skliper]

Is your feature request related to a problem? Please describe.
I realize we've discussed this before, but our unit tests are all over the place.

Describe the solution you'd like
We should implement gold-standard patterns, and drive the rest of the system towards that goal as we update unit tests. Really the ASSERT* macros at this point seem like the most informative/standard set but they aren't available to OSAL. Update the ut_assert macros or add ones that match this pattern.

Describe alternatives you've considered
None

Additional context
Developers have added all sorts of non-standard debug statements when if we just used the informative macros the output would be standardized (see #786)

Requester Info
Jacob Hageman - NASA/GSFC

[jphickey]

We cannot put everything in OSAL - Notably things like events (e.g. EVTSENT macro used by SB) does not apply.

I think we have a generic-enough "int32" check in the form of UtAssert_INT32_EQ() that can be used for return values pretty much globally.

I would like to see a simpler form of some of the other macros be available more globally, though. Basically all of the "older-style" ones that make the user supply their own message string. I very much prefer the ones that just print their arguments with a generic string - easier to use, and actually more informative when it fails.

[skliper]

I would like to see a simpler form of some of the other macros be available more globally, though. Basically all of the "older-style" ones that make the user supply their own message string. I very much prefer the ones that just print their arguments with a generic string - easier to use, and actually more informative when it fails.

Yeah, maybe it's just changing the built in ones in OSAL to behave like the cFE ones... I agree the argument print is much more straight forward.

[astrogeco]

CCB:2021-02-17 Discussed

[skliper]

Also should address #752 if not done already. See also #816 for all instances.

[skliper]

From side chats - really the goal here is to use common macros such that outputs and even hopefully the tests are similar enough as to allow for common processing and analysis patterns. Really trying to make cross checking of API documentation vs tests easier, reporting API coverage, and reducing technical debt due to having to handle each flavor differently. Consistently implemented patterns are easier to update.

[skliper]

Related to #484. Concept is to provide a guide as to what macros to use, how to extend (suggested ways to maintain consistency and scriptability, supporting automated verification, etc), where to put custom text if required, etc. Also conversion of all the less-desirable patterns used in the various testing flavors to the standard set.