Unit Testing With Function Mocking

[gamename]

Hi,

Currently, I'm using CUnit as a unit test tool. But there is one
thing it really lacks: function mocking. In other words, changing
what really gets called in subordinate routines so that a function
being tested has predictable behavior.

I know that CGreen has this ability, but it doesn't seem to work on
Cygwin. Also, its yet-another-tool to invest time on .
Is there any way to get this functionality in CUnit? Or, is there a
another tool that does a better job than CUnit or CGreen?

Any constructive ideas welcome.

Thanks,
-T

 

[Malcolm McLean]

Currently, I'm using CUnit as a unit test tool. But there is one
thing it really lacks: function mocking. In other words, changing
what really gets called in subordinate routines so that a function
being tested has predictable behavior.

I know that CGreen has this ability, but it doesn't seem to work on
Cygwin. Also, its yet-another-tool to invest time on .
Is there any way to get this functionality in CUnit? Or, is there a
another tool that does a better job than CUnit or CGreen?

Any constructive ideas welcome.

I'd be sceptical that you can effectively mock up a function with an
automatic tool. How does it know what is and what is not a side-effect
consistent with the call?

I am all in favour of unit tests, but I don't see them as a panacea. It
seems to be you might be reaching the point in development where the idea
begins to break down.

 

[Ian Collins]

Hi,

Currently, I'm using CUnit as a unit test tool. But there is one
thing it really lacks: function mocking. In other words, changing
what really gets called in subordinate routines so that a function
being tested has predictable behavior.

I know that CGreen has this ability, but it doesn't seem to work on
Cygwin. Also, its yet-another-tool to invest time on .
Is there any way to get this functionality in CUnit? Or, is there a
another tool that does a better job than CUnit or CGreen?

Any constructive ideas welcome.

You should be able to get away with something like this:

#include <stdio.h>

static int printf( const char* fmat, ...) { return 0; }

int main ( void ) {
int n;

printf( "%d\n", n );

return 0;
}

 

[Thad Smith]

Currently, I'm using CUnit as a unit test tool. But there is one
thing it really lacks: function mocking. In other words, changing
what really gets called in subordinate routines so that a function
being tested has predictable behavior.

I am just about to start working with a unit test framework (to be
chosen, then possibly modified). As part of the research, I have run
across some papers of using unit testing for embedded applications at
<http://atomicobject.com/pages/Papers>. As I recall, the author uses
separate files for the application and test stubs. They might have the
same name and reside in a different directory, have a mechanism for
selecting a particular include file, and/or using different linkage
commands for linking the stub version.

 

[Jack Klein]

You should be able to get away with something like this:

#include <stdio.h>

static int printf( const char* fmat, ...) { return 0; }

No guarantees, the behavior is specifically undefined.

"7.1.3 Reserved identifiers

Each header declares or defines all identifiers listed in its
associated subclause, and optionally declares or defines identifiers
listed in its associated future library directions subclause and
identifiers which are always reserved either for any use or for use as
file scope identifiers.

[snip]

Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is reserved for
use as a macro name and as an identifier with file scope in the same
name space if any of its associated headers is included."

 

[Ian Collins]

No guarantees, the behavior is specifically undefined.

Good point, printf was a bad example.

I was just illustrating that a function declared in a header can be
substituted with (overloaded by?) a static function.

 

[goose]

Good point, printf was a bad example.

I was just illustrating that a function declared in a header can be
substituted with (overloaded by?) a static function.

If thats the case, then
#define printf (void)

should do the job without trampling all over the standard
library.

 

[gamename]

I am just about to start working with a unit test framework (to be
chosen, then possibly modified). As part of the research, I have run
across some papers of using unit testing for embedded applications at
<http://atomicobject.com/pages/Papers>. As I recall, the author uses
separate files for the application and test stubs. They might have the
same name and reside in a different directory, have a mechanism for
selecting a particular include file, and/or using different linkage
commands for linking the stub version.

Thanks Thad. That's a good start.

 

[gamename]

If thats the case, then
#define printf (void)

should do the job without trampling all over the standard
library.

Rather than redifining printf (to use this example), could there be a
way to define each function entry address as a handle? In other
words, link in a "shim" layer that allows the user to change the
address of printf?

Thoughts?
-T

 

[Ian Collins]

Rather than redifining printf (to use this example), could there be a
way to define each function entry address as a handle? In other
words, link in a "shim" layer that allows the user to change the
address of printf?

Possibly, but that depends on your platform. Try asking this on a
platform specific group.

 

[gamename]

Possibly, but that depends on your platform. Try asking this on a
platform specific group.

Will do. Thanks.

-T