This subtree contains test library code that could aid in the writing of chip-level tests. Test library code consists of two components:
testutils
libraries, and- the on-device test framework.
Functions in testutils
libraries are designed to wrap several DIF invocations that are commonly used together across many chip-level tests.
They are not designed to wrap a single DIF call.
The on-device test framework provides a generic platform for writing chip-level tests.
- All
testutils
libraries should be placed insw/device/lib/testing/*
- The on-device test framework
code will live in:
sw/device/lib/testing/test\_framework
. testutils
libraries will be named:<IP or functionality name>_testutils.<h,c>
- All
testutils
function names should take on the following format:<IP or functionality name>_testutils_<function name>()
. This corresponds to the format:<filename>_<function name>()
. - All
testutils
functions should return status_t, if appropriate thekOk
return can encapsulate a value such as a bool.testutils
functions should never abort, which means thatCHECK*()
macros shall not be used but its siblingsTRY_CHECK*()
defined insw/device/lib/testing/check.h
instead. - All
testutils
functions should be marked with OT_WARN_UNUSED_RESULT to avoid mistakenly ignoring errors. - Try to keep
testutils
libraries toplevel agnostic (e.g., don’t includehw/top_earlgrey/sw/autogen/top_earlgrey.h
if you can avoid it). This meansdif_<ip>_init()
DIFs should be invoked in chip-level tests, nottestutils
, and the DIF handles should be passed in as parameters totestutils
functions. - Pass-through
sw/device/lib/dif_base.h
types where appropriate. This allows testutils functions to easily mix with DIFs within chip-level tests. - Avoid defining testutils that call a single DIF, and use the DIF directly. If a DIF does not exist for your needs, create one by following the DIF development guide.