1# Testing the CHRE Framework 2 3[TOC] 4 5The CHRE framework can be tested at various levels to ensure that 6components/modules components are working correctly and API contracts are being 7met. Below are some examples of what the team currently does to verify new 8changes. 9 10## Unit tests 11 12Currently, unit tests exist for various core components and utilities. Since 13platform-specific components likely aren’t compilable/available on a host 14machine, only components that are OS independent can be tested via this path. 15 16In order to write new tests, add a test source file under the test directory in 17the appropriate subdirectory. e.g. `util/tests`. Then, add the file to the 18`GOOGLETEST_SRCS` variable in the appropriate .mk file for that subdir, 19`util/util.mk` for example. 20 21Unit tests can be built and executed using `run_tests.sh`. 22 23## PAL implementation tests 24 25PAL implementation tests verify implementations of PAL interfaces adhere to the 26requirements of that interface, and are intended primarily to support 27development of PAL implementations, typically done by a chip vendor partner. 28Additional setup may be required to integrate with the PAL under test and supply 29necessary dependencies. The source code is in the files under `pal/tests/src` 30and follows the naming scheme `*_pal_impl_test.cc`. 31 32In order to run PAL tests, run: `run_pal_impl_tests.sh`. Note that there are 33also PAL unit tests in the same directory. The unit tests are added to the 34`GOOGLETEST_SRCS` target while PAL tests are added to the 35`GOOGLETEST_PAL_IMPL_SRCS` target. 36 37## FeatureWorld nanoapps 38 39Located under the `apps/` directory, FeatureWorld nanoapps interact with the set 40of CHRE APIs that they are named after, and can be useful during framework 41development for manual verification of a feature area. For example, SensorWorld 42attempts to samples from sensors and outputs to the log. It also offers a 43break-it mode that randomly changes which sensors are being sampled in an 44attempt to point out stress points in the framework or platform implementation. 45 46These apps are usually built into the CHRE framework binary as static nanoapps 47to facilitate easy development. See the Deploying Nanoapps section for more 48information on static nanoapps. 49 50## CHQTS 51 52The Context Hub Qualification Test Suite (CHQTS) tests perform end-to-end 53validation of a CHRE implementation, by using the Java APIs in Android to load 54and interact with test nanoapps which then exercise the CHRE API. While this 55code is nominally integrated in another test suite, the source code is available 56under `java/test/chqts/` for the Java side code and `apps/test/chqts/` for the 57CHQTS-only nanoapp code and `apps/test/common/` for the nanoapp code shared by 58CHQTS and other test suites. 59
