Zephyr Mocking

[Ben Byers]

Has anyone tried mocking any of the Zephyr APIs? I'm getting a ton of dependencies and we've given up on this route for now and are trying to write our own mock headers since using CMock wasn't providing enough separation of the modules.

[Mark Vander Voord]

I've not tried these API's specifically, but instead of writing your own mocks, it's much simpler to create headers that have the API portions you care about, and then let CMock do it's job. These headers can be used just for your tests and also serve to document which portions of the API you're using.

Mark

On Tue, Sep 13, 2022 at 2:55 PM Ben Byers <freckle...@gmail.com> wrote:

Has anyone tried mocking any of the Zephyr APIs? I'm getting a ton of dependencies and we've given up on this route for now and are trying to write our own mock headers since using CMock wasn't providing enough separation of the modules.

--
You received this message because you are subscribed to the Google Groups "ThrowTheSwitch Forums" group.
To unsubscribe from this group and stop receiving emails from it, send an email to throwtheswitc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/7907217a-89a7-44c0-8db0-9a0ae4c342e4n%40googlegroups.com.

[Ben Byers]

That's what I was hoping I wouldn't have to do haha. I'm going to basically abstract one more level and then unit test those instead of the very involved Zephyr APIs. The issue there seemed to be that the dependency chain is something we couldn't break.

[David Good]

Hey Ben !

It sounds like you know what you're doing already , but for those following along at home , I want to mention that you don't absolutely need to introduce the extra abstract layer if you don't want to . You can just create a header file with the actual Zephyr APIs you are using copies straight from the Zephyr .h files themselves . Then CMock can create clean mocks without bringing in whatever else is in those header files .

The other reason I mention this is because if you create this abstract layer and want to test it to make sure it does what it's supposed to , well .... you're right back where you started :)

--David

To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/52f90ec5-7469-4e02-8973-46e2c065a410n%40googlegroups.com.

[Ben Byers]

Hi David,

What I've done so far is basically take our own source file (button.c or something like that) that was including the zephyr/driver/gpio.h in order to use their GPIO API directly, and add one more level of abstraction. It originally looked like button.c-->zephyr/drivers/gpio.h, which was not mocking properly due to a bunch of other includes that were in gpio.h for Zephyr. Now it would be something like button.c-->gpio.h(mine)-->gpio.c(mine)-->zephyr/drivers/gpio.h and I can mock gpio.h(mine) since I removed the Zephyr API dependencies. You are correct in that I would run into the same issue if I wanted to unit test the gpio.c(mine) since it does include zephyr/drivers/gpio.h. 

I guess I don't see how creating a separate header zephyr_gpio.h(mine) where I cherry pick functions, which may need some of the problematic headers, would be helpful? Sounds like I'd end up with an extra header for every driver I want to use, which isn't necessarily a bad thing, but I guess I'm still not seeing how this would solve the mocking issue? 

I'm very open to ideas and suggestions so I appreciate your response!

Thanks,

Ben

[Ben Byers]

David,

We actually ended up going the route of copying and pasting the functions and definitions we needed. Thank you for the suggestion! As we discussed it as a team, that ended up prevailing because it keeps us the closest to the original APIs that are to be mocked. I did learn that others are trying to mock Zephyr APIs and there are problematic structures that some strip out using python scripts and then put those in a separate folder, so basically and automated way of doing this.

Thanks,

Ben

[David Good]

Awesome !

I was feeling kind of bad having not answered your previous email because I've not looked at the Zephyr APIs myself , so I'm glad you and your team were able to work it out :)

Cheers !

--David

To view this discussion on the web visit https://groups.google.com/d/msgid/throwtheswitch/ecd7e6a6-fe9c-40e1-a8f0-f272311d1aean%40googlegroups.com.