Yes, an API that perfectly fits my needs that I completely control.
It would be, but most mbed os API don’t provide virtual interface that you can mock with Google Mock. So I take it out of the equation. It also allows me, if needed, to replace the mbed API with my custom low level drivers, for the Pwm example, not use mbed::PwmOut but ST’s LL_PwmOut.
As I control the layer, I can then implement it however I want.
Testing is work. That’s why TDD is so great: you write tests first, so you never have to write tests again 
You don’t, unit tests should not have async features, that’s why you mock stuff, so you don’t have to wait for the database to respond.
Unit tests are for units of code. If a driver needs async stuff, then you’re not testing the driver, you’re testing the driver + the async stuff, so IMHO it’s not unit tests anymore.
You move to functional tests and then greentea can be your friend. But keep in mind that functional tests are harder to run, harder to debug, and cost time and money.
In our project, we made an arbitrary division between drivers and libs:
- drivers: talk directly to the hardware or use API that talk directly to the hardware with no RTOS except for
ThisThread::sleep_for() - libs: use drivers and RTOS API to create higher functionalities
Even in libs, the RTOS things can be stubbed away for unit tests and mbed provides a lot of stubs that you can use directly to do that.
I would not do functional tests on the host computer, it doesn’t make any sense. We have a very few functional tests, we manually run them before merging to test key components of the robot.
Every time we write a lib or driver, we also must provide a spike, a very simple program to show if and how it works.