Skip to content
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

Code in "unit-test" should use UT Assert #313

Closed
jphickey opened this issue Dec 12, 2019 · 0 comments · Fixed by #334
Closed

Code in "unit-test" should use UT Assert #313

jphickey opened this issue Dec 12, 2019 · 0 comments · Fixed by #334
Assignees
Milestone

Comments

@jphickey
Copy link
Contributor

Describe the bug
The tests in the "unit test" directory use an entirely different result reporting mechanism. Although they do currently link with UT assert, they keep a local record of test cases and do not use any of the UT assert functions.

This is a maintenance issue. The code makes extensive use of macros which makes it difficult to understand and also duplicates much of the logic that UT assert already has. Furthermore, the tests do not run on all OSAL platforms (e.g. RTEMS) because the macros are incomplete, even though UT assert does support this platform.

To Reproduce
Build with ENABLE_UNIT_TESTS=TRUE and run all tests. The osal "unit-tests" produce entirely different log files than the rest of the tests.

Expected behavior
The osal "unit-tests" should be more consistent in behavior and log file format with all the other tests.

System observed on:

  • Ubuntu 18.04 LTS 64-bit

Additional context
This is becoming more of an issue due to a parallel effort to avoid clobbering CMAKE_C_FLAGS (#312). But this unit test build currently relies on CMAKE_C_FLAGS and OS-specific definitions (e.g. _LINUX_OS_, _VXWORKS_OS_, etc) to pick the right macros to use. So this breaks the unit test if not setting CMAKE_C_FLAGS anymore.

Although it could probably be patched up again with some more hacks, it is probably worth some extra effort to just clean this up properly so it stops being a perpetual issue.

Since most things are macro based already, it is likely that simply changing the macro definitions to direct the output to UT assert instead of the local structure is probably sufficient.

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

@jphickey jphickey self-assigned this Dec 12, 2019
jphickey added a commit to jphickey/osal that referenced this issue Dec 13, 2019
Modify the "unit-tests" (extended/functional tests) for OSAL to use
the UT assert library for test case reporting and platform support.

Reduce or eliminate the use of macros for platform abstraction
wherever possible.

This removes most platform-specific logic from the test cases,
leaving that to the OSAL/BSP abstraction.
jphickey added a commit to jphickey/osal that referenced this issue Dec 13, 2019
Modify the "unit-tests" (extended/functional tests) for OSAL to use
the UT assert library for test case reporting and platform support.

Reduce or eliminate the use of macros for platform abstraction
wherever possible.  This removes most platform-specific logic from
the test cases, leaving that to the OSAL/BSP abstraction.
jphickey added a commit to jphickey/osal that referenced this issue Dec 13, 2019
Modify the "unit-tests" (extended/functional tests) for OSAL to use
the UT assert library for test case reporting and platform support.

Reduce or eliminate the use of macros for platform abstraction
wherever possible.  This removes most platform-specific logic from
the test cases, leaving that to the OSAL/BSP abstraction.
skliper pushed a commit that referenced this issue Dec 30, 2019
Modify the "unit-tests" (extended/functional tests) for OSAL to use
the UT assert library for test case reporting and platform support.

Reduce or eliminate the use of macros for platform abstraction
wherever possible.  This removes most platform-specific logic from
the test cases, leaving that to the OSAL/BSP abstraction.
skliper added a commit that referenced this issue Dec 30, 2019
Fix #295, #298, #305, #307, #308,
    #313, #314, #316, #321, #323
Reviewed and approved at 2019-12-18 CCB
@skliper skliper added this to the 5.1.0 milestone Jan 2, 2020
jphickey added a commit to jphickey/osal that referenced this issue Aug 10, 2022
Include in the basic warning set.  Note that at this time the CFE
does not build cleanly on all architectures with this warning enabled,
pending resolution of issue nasa#313.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants