Mocks - Espressif ESP32-S2 Programming Manual

Chapter 4. API Guides
The cache compensated timer is an alternative to placing the code/data to be benchmarked in IRAM/DRAM. This
timer uses the processor's internal event counters in order to determine the amount of time spent on waiting for
code/data in case of a cache miss, then subtract that from the recorded wall time.
// Start the timer
ccomp_timer_start();
// Function to time
func_code_to_time();
// Stop the timer, and return the elapsed time in microseconds relative to
// ccomp_timer_start
int64_t t = ccomp_timer_stop();
One limitation of the cache compensated timer is that the task that benchmarked functions should be pinned to a
core. This is due to each core having its own event counters that are independent of each other. For example, if
ccomp_timer_start gets called on one core, put to sleep by the scheduler, wakes up, and gets rescheduled on
the other core, then the corresponding ccomp_timer_stop will be invalid.

4.30.8 Mocks

Note: Currently, mocking is only possible with some selected components when running on the Linux host. In the
future, we plan to make essential components in IDF mockable. This will also include mocking when running on the
ESP32-S2.
One of the biggest problems regarding unit testing of embedded systems are the strong hardware dependencies.
Running unit tests directly on the ESP32-S2 can be especially difficult for higher layer components for the following
reasons:
• Decreased test reliability due to lower layer components and/or hardware setup.
• Increased difficulty in testing edge cases due to limitations of lower layer components and/or hardware setup
• Increased difficulty in identifying the root cause due to the large number of dependencies influencing the be-
havior
When testing a particular component, (i.e., the component under test), software mocking allows the dependencies
of the component under test to be substituted (i.e., mocked) entirely in software. To allow software mocking, ESP-
IDF integrates the CMock
ESP-IDF's build system, it is possible to conveniently mock the entirety (or a part of) an IDF component.
Ideally, all components that the component under test is dependent on should be mocked, thus allowing the test
environment complete control over all interactions with the component under test. However, if mocking all dependent
components becomes too complex or too tedious (e.g. because you need to mock too many function calls) you have
the following options:
• Include more"real"IDF code in the tests. This may work but increases the dependency on the"real"code'
s behavior. Furthermore, once a test fails, you may not know if the failure is in your actual code under tests or
the "real"IDF code.
• Re-evaluate the design of the code under test and attempt to reduce its dependencies by dividing the code under
test into more manageable components. This may seem burdensome but it is common knowledge that unit tests
often expose software design weaknesses. Fixing design weaknesses will not only help with unit testing in the
short term, but will help future code maintenance as well.
Refer to cmock/CMock/docs/CMock_Summary.md
use mocks.
Requirements
The following requirements are necessary to generate the mocks:
Espressif Systems
mocking framework as a component. With the addition of some CMake functions in the
for more details on how CMock works and how to create and
Submit Document Feedback
1508 Release v4.4