umock either has some look-ahead or it doesn't have or both at the same time

[anporumb]

The following sort of self-contained code has admirable behavior at runtime:

#define ENABLE_MOCKS
#include "umock_c/umock_c_prod.h"
MOCKABLE_FUNCTION(, void, sum, int, a, int, b);
MOCKABLE_FUNCTION(, void, whatIsDouble, int, a, int*, b);
#undef ENABLE_MOCKS

static void code_under_test1(void)
{
    sum(2, 4);
    sum(3, 5);
}

static void code_under_test2(void)
{
    int nothing;
    whatIsDouble(2, &nothing);
    whatIsDouble(3, &nothing);
}

TEST_FUNCTION(umock_test_code_under_test1)
{
    umock_c_reset_all_calls();
    
    STRICT_EXPECTED_CALL(sum(2, 4));
    code_under_test1();
    STRICT_EXPECTED_CALL(sum(3, 5));
    ASSERT_ARE_EQUAL(char_ptr, umock_c_get_expected_calls(), umock_c_get_actual_calls());
}

TEST_FUNCTION(umock_test_code_under_test2)
{
    umock_c_reset_all_calls();

    STRICT_EXPECTED_CALL(whatIsDouble(2, IGNORED_PTR_ARG));
    code_under_test2();
    STRICT_EXPECTED_CALL(whatIsDouble(3, IGNORED_PTR_ARG));
    ASSERT_ARE_EQUAL(char_ptr, umock_c_get_expected_calls(), umock_c_get_actual_calls());
}

Note the extreme similarities between the 2 tests, the only difference being the second test uses a pointer instead of the int used in the first test.

Both tests (umock_test_code_under_test1 and umock_test_code_under_test2) are poorly written and have a STRICT_EXPECTED_CALL after the code under test.

This is the expected behavior for umock_test_code_under_test1 : after code_under_test1 is called, there's going to be an actual call (sum(3, 5);) that is "extra" (actual). After STRICT_EXPECTED_CALL(sum(3, 5)); there is another "extra" (expected) call. They should not be matched because the expected call was not existing at the time when the actual call happened.

However, umock_c will happily match them and in the case of umock_test_code_under_test1 the test will happily pass.

umock_test_code_under_test2 produces the expected behavior (that is, the test will fail). However, even when the test fails (as expected) the message on the screen doesn't really help with understanding "why" it failed, because it looks very "should pass":

"well - if the second argument is ignored, how come the calls didn't match?".

Overall the expectation is that both tests should fail. And when they fail - the message on the screen should indicate better "why they failed".