[MOVED] Document nested usage of UT_ADD_TEST and clarify nomenclature for individual versus groups of tests

[astrogeco]

Describe the problem

The UT_ADD_TEST call has some limitations as addressed in nasa/cFE#840. Some solutions are discussed in that PR.

Proposed Solutions

1. Have UT_ADD_TEST handle "nested" unit tests, OR
2. Develop a nomenclature for unit test functions that explicitly indicates whether there are nested unit tests and then rename unit tests accordingly, OR
3. Document the anti-pattern, OR
4. Split up all unit tests to ensure only one test per function and make this a design pattern.

Additional Context

Originally posted by @skliper in nasa/cFE#840 (comment)

Related to #577. Individual tests are added w/ the UT_ADD_TEST call. Some tests are grouped at a lower level (Test_MSG_CCSDSExt is a group of tests), and those functions are called directly. Same pattern is used in sb:

https://github.com/nasa/cFE/blob/a148b97511de3f45f6677c1a3a0b17197f867e28/fsw/cfe-core/unit-test/sb_UT.c#L134-L135

[skliper]

This may belong in nasa/cfe, which own UT_ADD_TEST and UT_AddSubTest, and the unit tests that employ this model.

[astrogeco]

This may belong in nasa/cfe, which own UT_ADD_TEST and UT_AddSubTest, and the unit tests that employ this model.

ah I put it here since you mentioned UT_Assert :(

[skliper]

The osal relation is you shouldn't call UtTest_Add from within another test that was registered with UtTest_Add. This is the subject of #577.

[astrogeco]

Would it make sense to keep both of them open then? maybe reframe #577 as prevent that behavior or document it?

[astrogeco]

Edit: move this one to cfe but reopen and reframe #577 ?

[skliper]

I'm fine with however you want to handle it.

[astrogeco]

Moved to nasa/cFE#841