Calling FFF_RESET_HISTORY doesn't work well when checking a similar call order in two sequential tests. Since the reset only moves the index, but doesn't clear the history of calls, if two functions happen to have a similar sequence of faked calls, checking the call history in the tests can erroneously succeed even when FFF_RESET_HISTORY is called in between the test runs. I hit this in the context of faking locking/unlocking functions in my code. A pseudo-code scenario that I think demonstrates what I'm talking about below:
void functionAUnderTest(void)
{
fake1();
//do something
fake2();
}
void functionBUnderTest(void)
{
/* not implemented yet, but planned as shown*/
//fake1();
//do something different
//fake2();
}
void testA( void )
{
FFF_FAKES_LIST(RESET_FAKE);
FFF_RESET_HISTORY();
functionAUnderTest();
ASSERT_EQ(fff.call_history[0] == fake1);
ASSERT_EQ(fff.call_history[1] == fake2);
}
void testB( void )
{
FFF_FAKES_LIST(RESET_FAKE);
FFF_RESET_HISTORY();
functionBUnderTest();
//fake1 and fake2 pass, because they are still in the history, despite the reset
ASSERT_EQ(fff.call_history[0] == fake1); //passes even though haven't actually called the fake
ASSERT_EQ(fff.call_history[1] == fake2); //passes even though haven't actually called the fake
}
I can't promise when I'll get to it, but would a PR to extend the reset to also actually clear the history be welcomed?
Calling FFF_RESET_HISTORY doesn't work well when checking a similar call order in two sequential tests. Since the reset only moves the index, but doesn't clear the history of calls, if two functions happen to have a similar sequence of faked calls, checking the call history in the tests can erroneously succeed even when FFF_RESET_HISTORY is called in between the test runs. I hit this in the context of faking locking/unlocking functions in my code. A pseudo-code scenario that I think demonstrates what I'm talking about below:
I can't promise when I'll get to it, but would a PR to extend the reset to also actually clear the history be welcomed?