Variadic macro extensions to the FFF

[cormacc]

This uses some VA_ARGS counting and iteration macros to reduce the boilerplate required when verifying calls to functions with multiple parameters, setting up return value sequences etc. Also allows to check for any call to a given function with a specified set of parameters.

Useful in my own codebase at least (embedded C) -- may be of more general interest.

This is a proposal for a PR for now. Packaged as two separate headers for clarity, and to save myself a bit of effort if you're not interested in adding the functionality - I'll integrate them with your generator if you confirm interest. The va_args iteration macros in vaiter64.h are already ruby-generated anyway.

See header comment in fff_ext.h for details -- summary extracted below:

N.B. tested with GCC

Return value macros:

FFF_RETURN(function_name, ...)
Accepts a raw list of appropriately typed values

Assertion macros:

FFF_ASSERT_CALLS(function_name, expected_call_count)

FFF_ASSERT_CALLED(function_name)
Only one call made to the function.

FFF_ASSERT_NOT_CALLED(function_name)
No calls made to the function

FFF_ASSERT(function_name, ...parameters)
Only one call made to the function (verifies parameter values if provided).

FFF_ASSERT_LAST(function_name, ...parameters)
The final call to this function was made with the specified parameter values.

FFF_ASSERT_ANY(function_name, ...parameters)
At least one call was made with the specified parameter values.

FFF_ASSERT_NONE(function_name, ...parameters)
No calls were made with the specified parameter values.

FFF_ASSERT_NTH(function_name, call_index, ...parameters)
A specified invocation of the function used the specified parameter values.

The assertion macros use <assert.h> by default, but overridable. I'm using Ceedling/Unity, and do this:
``
#define _FFF_ASSERT_EQ_MSG(expected, actual, message) TEST_ASSERT_EQUAL_MESSAGE(expected, actual, message)

#include "fff.h"
``

Cobbled these together while switching an existing codebase from using cmock -- much happier with the approach adopted by the fff -- allows me to construct less brittle tests. Thanks for the tool

[rubiot]

This would make a very good addition. I've had to write these boilerplate several times.

[meekrosoft]

This looks good to me...thanks for taking the time to contribute!

Some ways forward I can see:

• Integrate with the generator
• Need to provide unit tests
• Some documentation updates

[cormacc]

Great! Busy with family over the weekend, but should get back to it early next week.

…

On Fri, 6 Apr 2018 at 13:19 Mike Long ***@***.***> wrote: This looks good to me...thanks for taking the time to contribute! Some ways forward I can see: - Integrate with the generator - Need to provide unit tests - Some documentation updates — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#48 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADmzi5qYxaLs-SbfIH4P0v_0q18e6ZBuks5tl11egaJpZM4TIWTz> .

[cormacc]

Great! Busy with the family over the weekend, but should get back to it early next week.

[cormacc]

FYI, I've eliminated SET_RETURN_VAL and renaming SET_RETURN_VAL_SEQ to SET_RETURN, in the interest of API simplicity.
Given that the behaviour when a sequence is exhausted is to repeat the last value,

MyFn_fake.ret_val = 3;

is functionally identical to

int retseq[] = {3};
SET_RETURN_VAL_SEQ(MyFn, retseq, 1);

even if the implementation is different under the hood, the end-user doesn't care.
i.e.

SET_RETURN(MyFn, 1);
SET_RETURN(MyFn, 1, 2, 3);

[cormacc]

I've added unit tests, updated the generator and made some initial documentation updates. That probably needs a bit more but, @meekrosoft, you might have some preference for how you want the new functionality presented in relation to the existing interfaces? I've updated the hello world examples to show both syntaxes, and added most of the new functions to the cheat sheet.

I've renamed my args counting / iteration macros for consistency with what was there already and tried to maintain some consistency in the assertion function naming. Think that's it...

Oh, just added tests to the fff_test_c via a new .include file. Not sure on the relationship between the multiple test source files that include some of the same tests and didn't want to add them willy nilly.

[meekrosoft]

Great!
I'm a bit snowed under with work, but I;ll take a look over the next couple of days....

[cormacc]

If you're wondering about the include guards around the PP_NARG macro definitions, they're because I use them in production code as well as test, and otherwise get a lot of noisy macro redefinition warnings when running tests.

[wulfgarpro]

@cormacc, please resolve your conflicts before review moves forward.

[cormacc]

@wulfgarpro I'll definitely get back to this, but labouring under a pretty ridiculous workload til mid-january (one-man dev team in a medical device startup), and had actually gone a good way to a more concise set of vaargs macros based on some tail recursion ideas I came across in a blog post somewhere (i.e. don't have to hardcode a max arg count) since raising this PR, so . May well fit it in along the way, as I'm working on an embedded codebase that uses this. But could be as late as, well, late Jan. Well done for stepping in by the way -- just saw the cry for help post a few minutes ago -- great tool, would be a shame to let it fade away.

[cormacc]

... and January turns into June :S. The ridiculous workload lasted longer than anticipated.
Finally got around to tidying up the tail-recursion stuff in the PP_EACH generator. Earlier implementation required std=gnu99, but now works with std=c99.

Closing out a release here, but will come back and rebase/resolve conflicts in the next couple of weeks.

[AppVeyorBot]

❌ Build fff 58-appveyor failed (commit 0e64cb5d00 by @)

[AppVeyorBot]

❌ Build fff 59-appveyor failed (commit bbec0cdd77 by @)

[cormacc]

@wulfgarpro Finally got around to rebasing this etc. between a long flight delay a couple of weeks back and a slow test report export from Jira today :)
Now works with std=c99 or std=gnu99 (though 0-counting case only works with gnu99 -- test included or excluded at compile time by sniffing for some gcc macros).

I think I've respected a recent change w.r.t. MSVCC calling conventions, but don't have access to a windows testbed to verify. Anyway, probably some more work to be done, but external feedback would be useful at this stage. I'll be away for the next week, but should have a bit of bandwidth after that.

[AppVeyorBot]

❌ Build fff 60-appveyor failed (commit e7a2bb8ce7 by @)

[AppVeyorBot]

❌ Build fff 61-appveyor failed (commit b80ecb0a73 by @)

[AppVeyorBot]

❌ Build fff 75-appveyor failed (commit b8323ac511 by @)

[AppVeyorBot]

❌ Build fff 76-appveyor failed (commit 2cb4fc75e8 by @)

[AppVeyorBot]

❌ Build fff 77-appveyor failed (commit 7b488744c3 by @)

[AppVeyorBot]

❌ Build fff 78-appveyor failed (commit 3782c44e3e by @)

[AppVeyorBot]

❌ Build fff 79-appveyor failed (commit 12d4a5931c by @)

[cormacc]

If at first you don't succeed -- give up :) I'm really beginning to hate MSVC.
Parking for now until I have time to setup a windows/MSVC environment to test in -- not getting enough info from the appveyor build to diagnose where the issues are.

[cormacc]

@wulfgarpro See here:
https://devblogs.microsoft.com/cppblog/msvc-preprocessor-progress-towards-conformance/
that MS seem to be phasing in a more compliant preprocessor. Any leeway to use this? Even if not, I may try getting the build working using the new preprocessor and work back from that point or something (i.e. close a smaller gap first... gcc->new msvc->old msvc)

[AppVeyorBot]

❌ Build fff 128-appveyor failed (commit 41a8ae1504 by @)

[AppVeyorBot]

❌ Build fff 130-appveyor failed (commit e883ccb399 by @cormacc)