When i was implementing the new native type unsigned integer i noticed something a little odd on MockActualFunctionCall:

MockFunctionCall& MockActualFunctionCall::andReturnValue(unsigned int)
{
    FAIL("andReturnValue cannot be called on an ActualFunctionCall. Use returnValue instead to get the value.");
    return *this;
}

MockFunctionCall& MockActualFunctionCall::andReturnValue(int)
{
    FAIL("andReturnValue cannot be called on an ActualFunctionCall. Use returnValue instead to get the value.");
    return *this;
}

MockFunctionCall& MockActualFunctionCall::andReturnValue(const char*)
{
    FAIL("andReturnValue cannot be called on an ActualFunctionCall. Use returnValue instead to get the value.");
    return *this;
}

MockFunctionCall& MockActualFunctionCall::andReturnValue(double)
{
    FAIL("andReturnValue cannot be called on an ActualFunctionCall. Use returnValue instead to get the value.");
    return *this;
}

MockFunctionCall& MockActualFunctionCall::andReturnValue(void*)
{
    FAIL("andReturnValue cannot be called on an ActualFunctionCall. Use returnValue instead to get the value.");
    return *this;
}

It is a little odd to a object to implement a method only to fail since it cant implement the method, it seems that the MockFunctionCall has methods that does not belong only to a function call abstraction, but actually to a MockExpectedFunctionCall.

Since on MockSupport we have different methods for actual and expected calls i dont get exactly why all the methods must be on the same interface. The concept of the interface is nice, but it seems to do more than it should (a case of interface segregation perhaps).

The methods defined on MockFunctionCall that does no seem to belong there are:

virtual MockFunctionCall& andReturnValue(int value)=0;
virtual MockFunctionCall& andReturnValue(unsigned int value)=0;
virtual MockFunctionCall& andReturnValue(double value)=0;
virtual MockFunctionCall& andReturnValue(const char* value)=0;
virtual MockFunctionCall& andReturnValue(void* value)=0;

Is it the case of refactoring this on some way or im just missing the point ?

Currently, I am still sort-of maintaining the TI C2000 compiler, which is a 16 bit compiler, every now and again. This will come to an end at some point, at the latest, when I don't have access to a license anymore.

I noticed that, with this compiler, I tend to run into typical 16-bit platform related issues every now and again. These are not specifically related to the TI C2000 compiler, but would most likely occur on any 16 bit platform.

My question here is whether we could setup either Travis CI or Appveryor (or use anything else that is open-source) to test CppU against a 16 bit platform, possibly using a simulator? Or would that be too much of an effort? Are there 16 bit users out there at all? Does it even make sense to run CppU on such a target / platform? For instance, due to memory limitations, I needed to divide up the CppU test base into four separate binaries.

What are everybody's ideas on this? How relevant are 16 bit platforms for running CppU on?

Initial support for output parameters.

The implementation doesn't do any copying, it merely takes a value (primitive or pointer) and sets the output pointer to this value.

Support is added to all Mock classes, including the C support.

Just wondering, because I accidentally compiled it with a 64 bit compiler...

It would be pretty easy to make the code 64 bit-ready, but considerably harder to maintain 32-bit compatibility at the same time...

Example: You need StringFrom(size_t) (for 64 bit). You need StringFrom(uint32_t) (for Cpp library). This is considered a redeclaration by 32 bit compiler. You need unsigned long long etc. for 64 bit. 32 bit compiler (iso c98) does not know it. etc. etc.

It was hard to think on a title to this issue :-). Basically i realized that two things changed on the output when i run the tests:

1 - It says 2 tests have been run, it was much more awesome to see 2XX and 3XX tests running :-)

2 - This is the saddest, when there is an error the old report would populate my vim quickfix list and i would jump to the first test that crashed (being able to use the quickfix list to navigate through all the failed tests). Now when the tests fail i get nothing :-(. Instead of a awesome quickfix list i get a file to open (tests-log or someting like that) to see what went wrong.

I'm sorry if this is something that has already been debated, i tried to find something on the open issues about this, but had no success.

Using a typedef inside the correct space (C or C++) is the only way to make a function pointer C-ish or Cpp-ish. It is also elegant and simple.

I won't waste any more time on attempted hacks that invariably don't work.

I got crazy by tracking down a double free issues with CPPUtest and I could narrow down the problem. The problem seems to come when I use a reference as an output parameter, it complains about double freeing the field in the referenced object. As always, an example is clearer than too many words:

#include <string>

#include <CppUTest/CommandLineTestRunner.h>
#include <CppUTest/TestHarness.h>
#include <CppUTestExt/MockSupport.h>

//--------------------------------------------------------------------------------------------
class MyReference
{
public:
    MyReference():
      m_name("Hello")
    {
    }
    ~MyReference(){}

private:
    // If I remove this field, it works as expected
    std::string m_name; // Double freed!!!??
};

//--------------------------------------------------------------------------------------------
class ReturnReference
{
public:
    ReturnReference(){}
    virtual ~ReturnReference(){}

    virtual bool returnReference(MyReference& ref)
    {
        ref = m_ref;
        return true;
    }
private:
    MyReference m_ref;
};

//--------------------------------------------------------------------------------------------
class ReturnReferenceMock:
        public ReturnReference
{
public:
    ReturnReferenceMock(){}
    ~ReturnReferenceMock(){}

    bool returnReference(MyReference& ref)
    {
        return mock().actualCall("returnReference").onObject(this).
                withOutputParameter("ref", &ref).returnIntValue();
    }
};

//--------------------------------------------------------------------------------------------
class UseReturnReference
{
public:
    UseReturnReference(ReturnReference* returnReference) :
        m_pReturnReference(returnReference)
    {
    }

    ~UseReturnReference()
    {
        delete m_pReturnReference;
    }

    void useReturnReference()
    {
        MyReference ref;
        m_pReturnReference->returnReference(ref);
    }

private:
    ReturnReference* m_pReturnReference;
};

//--------------------------------------------------------------------------------------------
TEST_GROUP(TestReferenceMock)
{

    TEST_SETUP()
    {
        // XXX: Double free!
        //MemoryLeakWarningPlugin::turnOffNewDeleteOverloads();
    }

    TEST_TEARDOWN()
    {
        mock().clear();
        MemoryLeakWarningPlugin::turnOnNewDeleteOverloads();
    }
};

TEST(TestReferenceMock, willItFail)
{
    ReturnReferenceMock* retRefMock = new ReturnReferenceMock();
    UseReturnReference useRef(retRefMock);
    MyReference* ref = new MyReference();

    mock().expectOneCall("returnReference").onObject(retRefMock).
            withOutputParameterReturning("ref", ref, sizeof(*ref)).
            andReturnValue(true);

    useRef.useReturnReference();

    mock().checkExpectations();

    // Not doing this reports a memory leak as expected!
    delete ref;
}

TEST(TestReferenceMock, willItFail2)
{
    ReturnReferenceMock* retRefMock = new ReturnReferenceMock();
    UseReturnReference useRef(retRefMock);
    MyReference ref;

    mock().expectOneCall("returnReference").onObject(retRefMock).
            withOutputParameterReturning("ref", &ref, sizeof(ref)).
            andReturnValue(true);

    useRef.useReturnReference();

    mock().checkExpectations();
}

//--------------------------------------------------------------------------------------------
int main(int argc, char* argv[])
{
    // Run the tests
    return CommandLineTestRunner::RunAllTests(argc, argv);
}

The previous snippet reports the following error:

main.cpp:112: error: Failure in TEST(TestReferenceMock, willItFail2)
willItFail2:112: error:
    Deallocating non-allocated memory
   allocated at file: <unknown> line: 0 size: 0 type: unknown
   deallocated at file: <unknown> line: 0 type: delete


.
main.cpp:94: error: Failure in TEST(TestReferenceMock, willItFail)
willItFail:94: error:
    Deallocating non-allocated memory
   allocated at file: <unknown> line: 0 size: 0 type: unknown
   deallocated at file: <unknown> line: 0 type: delete
.
Errors (2 failures, 2 tests, 2 ran, 6 checks, 0 ignored, 0 filtered out, 0 ms)

This seems a bug in CPPUnit to me. However, the bug might probably come from a missuse of the library, but what am I doing wrong? Is it really possible to pass a reference as output parameter?

I based this off of the progress that @arstrube made. It is a little rough around the edges, but it copies the expected value to the output parameter only after the expected call has been selected (in MockCheckedActualCall::finalizeCallWhenFulfilled).

It currently passes the tests that @arstrube wrote. More polish and more tests will be needed if this looks like a direction we want to go.

When testing code that needs to work on both 64-bit platforms and 32-bit platforms, the long integer may not guarantee 64bits of width on the 32-bit platform. This makes testing calls which take and return 64bit values difficult, as the test framework can't handle these natively.

Add support for long long integers, so that test code can natively handle these larger values.

Signed-off-by: Jacob Keller [email protected]

1. Moved into a folder in platforms. This way, different Eclipse projects can be created per platform. This one is for Windows/Cygwin.
2. Utilizes Eclipse C/C++ Unit test plugin. You can re-run selected tests, etc. like with JUnit.
3. Build artifacts are put into cpputest_build folder.
4. Before using the Eclipse project, you should
   • cd cpputest_build
   • autoreconf .. -i #if necessary
   • ../configure Works on my home and work machines, so I hope it will work for others.

I built CppUTest with Visual Studio 2013, and ran into some issues. I managed to figure it out, so here is a summary in case you want to do changes in the sources or the documentation.

• Cmake did not produce any makefiles, so the make (or nmake) wouldn't work as documented. What I did get was a solution (.sln) file and .vcxproj files. I can build those with msbuild from commandline or open them in the IDE.
• The current build gives a warnings, and since warnings are treated as errors the build fails. All warnings are related of "unsafe" string functions:

..\Platforms\VisualCpp\UtestPlatform.cpp(123): warning C4996: 'strcpy': This
function or variable may be unsafe. Consider using strcpy_s instead. To 
disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
[C:\projects\cpputest\src\CppUTest\CppUTest.vcxproj]

Since we are dealing with test code, and the *_s functions are MS specific I went for the disable option by adding the following to the CMakeList.txt file:

if(MSVC)
    add_definitions(-D_CRT_SECURE_NO_WARNINGS)
endif(MSVC)

• There is no .lib files in the lib folder. Haven't figured out why yet.

Firstly some background:

We use C++ exceptions for exploding fakes. The exception is caught in main() and a backtrace is produced to help the developer understand the code path that has now caused the exploding fake to be called.

We are updating to a recent version of CppUTest but have to build it with CPPUTEST_HAVE_EXCEPTIONS defined as 0; otherwise the portion of the stacktrace inside the code under test is lost and the backtrace only ever traces down to the catch(...) in UTest.cpp.

The problem:

One of the platforms that where we need to use CppUTest is CentOS 7 (yes, it is old but still supported until June 2024) with GCC 4.8.5. When trying to build CppUTest without exceptions, it seems that GCC of that vintage is requiring the correct exception specification for the standard delete overloads. For example:

/cue/tm_win32_tools/cpputest/cpputest/src/CppUTest/MemoryLeakWarningPlugin.cpp: In function 'void operator delete(void*)':
/cue/tm_win32_tools/cpputest/cpputest/src/CppUTest/MemoryLeakWarningPlugin.cpp:330:31: error: declaration of 'void operator delete(void*)' has a different exception specifier
 void operator delete(void* mem) UT_NOTHROW
                               ^
In file included from /cue/tm_win32_tools/cpputest/cpputest/include/CppUTest/MemoryLeakWarningPlugin.h:32:0,
                 from /cue/tm_win32_tools/cpputest/cpputest/include/CppUTest/TestHarness.h:45,
                 from /cue/tm_win32_tools/cpputest/cpputest/src/CppUTest/MemoryLeakWarningPlugin.cpp:28:
/cue/tm_win32_tools/cpputest/cpputest/include/CppUTest/MemoryLeakDetectorNewMacros.h:70:10: error: from previous declaration 'void operator delete(void*) noexcept (true)'
     void operator delete(void* mem) UT_NOTHROW;
          ^

The solution?

Looking in CppUTestConfig.h, it looks like Clang might have a similar requirement:

  #if CPPUTEST_HAVE_EXCEPTIONS
    [...snip...]
  #else
    #define UT_THROW(exception)
    #ifdef __clang__
      #define UT_NOTHROW throw()
    #else
      #define UT_NOTHROW
    #endif
  #endif

If I extend the pattern to include GCC, it then builds successfully and cleanly for both the old version of GCC and more recent versions:

  #if CPPUTEST_HAVE_EXCEPTIONS
     [...snip...]
  #else
    #define UT_THROW(exception)
    #if defined(__clang__) || defined(__GNUC__)
      #define UT_NOTHROW throw()
    #else
      #define UT_NOTHROW
    #endif
  #endif

I will create a PR with this change so that it can be discussed and/or accepted as appropriate.

Thanks,

Steve.

None of the available GitHub actions allow us to "move" an existing latest-passing-build tag. GitHub expects tags to go unmutated. It seems we've been trying to use a tag as a branch.

I think this is fine. We shouldn't be merging anything that doesn't build; master effectively serves the same purpose.

How to write mock tests in cpputest , what is the need of mock in function , what is the use of that , in what cases we need to use mocking . Can you give some examples.

This is undefined behavior and has been failing very frequently on CI. The custom delete implementation calls free().

The behavior is undefined if after free() returns, an access is made through the pointer.

https://en.cppreference.com/w/c/memory/free