How to test particular pattern (return through runtime assigned func pointer)

[MikeExMachina]

I keep running into this pattern in my code and it's not super clear how to test it within ceedling. Basically I have a module that has some init function in which I provide it with pointers to a callback, and save that pointer in the module for later use. Ideally I would want to write my unit tests to have an "Expect" for these runtime assigned callbacks, but cmock obviously doesn't know to mock these functions because the pointers are technically declared within the module under test. I could think of a convoluted way to make this work, I could abstract away storing and calling these function pointers into its own module, which would then be easily mocked, but I'm hoping there's a "native" way to support this, maybe something to do with the "return through pointer" plugin that I'm not wrapping my head around?

[mvandervoord]

Hi.

At the moment, we don't have an automatic way to do this. There are two versions of this pattern that I see frequently... One is more easily testable than the other.

Version 1: The init function accepts the function pointers as arguments.
Version 2: The init function assigned the function pointers internally to module-scoped static functions.

I believe you're talking about version 1, which is the better of the two scenarios.

When I encounter version 1, I usually make a header file specifically for testing these callbacks (often I just call it callbacks_<original_filename>.h and put it in the support folder). The only thing in this header file are prototypes for the types of callbacks that get passed to init.

In the test, I can then mock the callback header, include the real header for testing, and then have setUp call init, passing the mocks to it. After this point, everything should behave as you'd expect.

I've done it enough that I've considered turning it into a plugin for CMock... but I was never sure if others rarely run into this. Apparently I have at least a second vote for turning it into a real feature. :)

(For those who find themselves in version 2 of this problem, you're basically in the same situation as anyone else testing a combination of static and non-static functions. We're also hoping to soon improve the ease-of-use for this situation, but for now, you'll want to look at our existing advice on handling these situations).

[MikeExMachina]

Awesome! Thank you so much for talking me through that. I feel like I run into this pattern all the time, maybe its just the way I like to architect things. For simple cases where the callback doesn't take any arguments, I've resorted to just creating a boolean flag in the test and a helper function that I would pass into the module as the callback that would just set that boolean when called. That way I could check the boolean from within the test to validate that the callback was actually called when I expected it to be. That strategy of course breaks down the second your callback takes any arguments you wanna validate. I'll give your strategy a try and I totally support adding a plugin for this use case!

[PVeps]

@mvandervoord Apparently I have at least a second vote for turning it into a real feature. :)
Once vote more! 😄
I am already using the solution you suggested. A small additional effort is to create the header with the function prototype, which is not that difficult. Describing this technique in the documentation would be useful for users.