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

Improve consistency in the result reporting in "unit-tests" #981

Closed
jphickey opened this issue May 4, 2021 · 0 comments · Fixed by #1001 or #1006
Closed

Improve consistency in the result reporting in "unit-tests" #981

jphickey opened this issue May 4, 2021 · 0 comments · Fixed by #1001 or #1006
Assignees
Milestone

Comments

@jphickey
Copy link
Contributor

jphickey commented May 4, 2021

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):

UT_RETVAL(OS_BinSemCreate(&sem_ids[0], NULL, 1, 0), OS_INVALID_POINTER, "null pointer arg 2");

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:

testDesc = "#2 Null-pointer-arg-2";
res = OS_ModuleLoad(&module_id, 0, UT_OS_GENERIC_MODULE_NAME1, OS_MODULE_FLAG_LOCAL_SYMBOLS);
if (res == OS_INVALID_POINTER)
UT_OS_TEST_RESULT(testDesc, UTASSERT_CASETYPE_PASS);
else
UT_OS_TEST_RESULT(testDesc, UTASSERT_CASETYPE_FAILURE);

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.

@jphickey jphickey self-assigned this May 10, 2021
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
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.
@skliper skliper added this to the 6.0.0 milestone Sep 24, 2021
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants