...
We are doing a lot of RTOS stuff, which we'd need to mock
Cmock's autogenerated mocks require looking at the function and seeing what is called instead of looking at the I/O of the function. Meaning when implementation changes the unit test will be invalid
RTOS support:
We can have some helper functions in our unit testing code to blackbox all RTOS calls and make them return true or success so we can test logic without RTOS easily
BSP testing:
We can (reasonably) say that the STM32 HAL functions work, so we can ensure in our BSP_I2C_Write() function, we're calling HAL_I2C_Write() with the proper function arguments
Test cases where queue's are full or empty
Trace macros
Let's see if we can use trace macros to test if we enter specific states in our function
Use the macro that is called when we block on a mutex indefinitely to see if we ever infinite block in an interrupt
Driver testing:
If we make our drivers use RTOS functions, we can pass in fake data structures (could be queues) and see if it either adds to the output data structure properly, and it tests for blocking access
Same logic as BSP testing where we assume BSP calls work fine, and ensure that my function calls the correct BSP function with the correct arguments the correct amount of times
Dependency injection is a pretty common tactic, but is mostly useful used in C++
Task testing:
this one kinda sucks
For basic logic tests we have all RTOS functions return success or nothing, just to test if our logic without RTOS is correct
Ie BPS trips when I pass in an array full of voltages that 69420 mV
...