-
Notifications
You must be signed in to change notification settings - Fork 224
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
Improve consistency in the result reporting in "unit-tests" #981
Comments
jphickey
added a commit
to jphickey/osal
that referenced
this issue
May 12, 2021
Update most of the conditions in the "unit tests" to use the support macros whenever possible. The macros display the function being called as well as the return value being checked for, and therefore this makes it so the test log file can be cross referenced back to the documentation to ensure the documented return codes are being tested. As a nice side effect this also removes quite a bit of repetition in the test programs.
jphickey
added a commit
to jphickey/osal
that referenced
this issue
May 12, 2021
Update most of the conditions in the "unit tests" to use the support macros whenever possible. The macros display the function being called as well as the return value being checked for, and therefore this makes it so the test log file can be cross referenced back to the documentation to ensure the documented return codes are being tested. As a nice side effect this also removes quite a bit of repetition in the test programs.
jphickey
added a commit
to jphickey/osal
that referenced
this issue
May 12, 2021
Update most of the conditions in the "unit tests" to use the support macros whenever possible. The macros display the function being called as well as the return value being checked for, and therefore this makes it so the test log file can be cross referenced back to the documentation to ensure the documented return codes are being tested. As a nice side effect this also removes quite a bit of repetition in the test programs.
astrogeco
added a commit
that referenced
this issue
May 12, 2021
Fix #981, rework "unit-tests" to use macros
pepepr08
pushed a commit
to pepepr08/osal
that referenced
this issue
Jun 9, 2021
Update most of the conditions in the "unit tests" to use the support macros whenever possible. The macros display the function being called as well as the return value being checked for, and therefore this makes it so the test log file can be cross referenced back to the documentation to ensure the documented return codes are being tested. As a nice side effect this also removes quite a bit of repetition in the test programs.
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Aug 10, 2022
Implmements a new function in FS to parse an input file name from a user. Initially applied to startup script processing. The new function produces fully-qualified output where the input may omit either a pathname or an extension. These items will be added from the specified defaults, if missing, and a complete fully-qualified filename will be output. If the input is already a fully qualified filename, then the output is the same as the input (basically a copy). This initially is used to provide better cross-platform startup script processing, where module suffix may differ across platforms. Only the "basename" of the filename needs to be specified in the startup script - everything else can come from defaults.
jphickey
pushed a commit
to jphickey/osal
that referenced
this issue
Aug 10, 2022
…rser Fix nasa#981, implement better filename parser
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
In order to be able to cross check and confirm that the unit tests are actually checking for the status codes that they should be, the test cases need to be clear about the API being called and the return value/status code being tested for in that test case. However, the functional tests are currently not consistent in how results are reported.
Describe the solution you'd like
Example from the binsem test, which is better because it at least uses a macro that includes both the function name/API being called (
OS_BinSemCreate
) as well as the status code being tested for (OS_INVALID_POINTER
):osal/src/unit-tests/oscore-test/ut_oscore_binsem_test.c
Line 84 in a061666
Which translates to a line like this in the log file:
[ PASS] 05.002 ut_oscore_binsem_test.c:84 - OS_BinSemCreate(&sem_ids[0], NULL, 1, 0) (-2) == OS_INVALID_POINTER (-2): null pointer arg 2
However a similar test case from OS_ModuleLoad displays neither:
osal/src/unit-tests/osloader-test/ut_osloader_module_test.c
Lines 99 to 105 in a061666
The latter translates only to a line like this in the log file, which doesn't say much at all:
[ PASS] 01.002 ut_osloader_module_test.c:103 - #2 Null-pointer-arg-2
A clear and concise description of what you want to happen.
Additional context
This is a prerequisite to completing #331 - The information in the log file needs to be made more like the BinSem case, so it can be cross referenced back to confirm the functional tests are checking for the items they are supposed to be checking for.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: