Understanding UnitTestLib's scope / general off-device FW testing question

Hi--I'm trying to set up some off-device unit testing for our system, and I found my way to https://github.com/rickkas7/UnitTestLib. It's been super helpful, for at least getting some basics compiling, but I've hit some issues since then that I'm hoping someone can give me some guidance on.

Some context: I'm pretty green at all this, so apologies in an advance for silly/naive questions. In addition, I think our current setup is probably not very well structured for unit tests, so I recognize that changing that may be necessary to moving forward.

My basic question is: what should I expect to get properly mocked via UnitTestLib? I gather that using it enables me to compile code that uses at least some portions of Particle.h (String/etc). I think I have been able to get this out of it. But if my libraries make use of, say, GitHub - rickkas7/BackgroundPublishRK: Library for doing Particle publish from a worker thread or GitHub - adafruit/Adafruit_SHT4X: Arduino driver for Adafruit SHT4X temperature / humidity breakout, should this be feasible? When I try to do so, I start to hit errors like unknown type name 'os_mutex_recursive_t', or just plain 'Arduino.h' file not found.

Is this as expected--that is, are these types/libraries outside the purview of UnitTestLib? If so, do I have any options for off-device testing--e.g. via other resources like it? Some of these missing types are probably manually mockable by me, but I'm not yet sure what would happen if I followed the chain all the way--would I likely end-up at a place where I essentially needed to re-implement on-device behavior to test code that uses libraries like these?

Thanks for your help, and sorry again if these questions are inane--just trying to find my footing here.

It's not intended to replace anything that's cloud related including any publish (background or not), or any device features like I2C, Serial, etc.. It's only intended to test business logic, basically.

Some examples of where it's used include:

Thanks for the reply!

I guess maybe part of the issue is that our "business logic" also includes things like event loops that interact with these device APIs. I guess manual mocking would be the way forward there?

Thanks again.

Yes, you will need to handle manually mocking things. There are some examples in the Device OS source code of a few different ways automated tests are done, but not all are easily implemented for user firmware, so that's not an easy solution either. Both on-device and off-device tests are done for releases.