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]

"gamename" <na***************@yahoo.comwrote in message

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.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ian Collins]

gamename wrote:

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;
}

--
Ian Collins.

[Thad Smith]

gamename wrote:

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.

--
Thad

[Jack Klein]

On Sat, 17 Mar 2007 11:30:59 +1300, Ian Collins <ia******@hotmail.com>
wrote in comp.lang.c:

gamename wrote:

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; }

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."

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Ian Collins]

Jack Klein wrote:

On Sat, 17 Mar 2007 11:30:59 +1300, Ian Collins <ia******@hotmail.com>
wrote in comp.lang.c:

>>gamename wrote:

>>>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; }

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.

--
Ian Collins.

[goose]

On Mar 17, 7:53 am, Ian Collins <[e-mail]:

Jack Klein wrote:

On Sat, 17 Mar 2007 11:30:59 +1300, Ian Collins <[e-mail]>
wrote in comp.lang.c:

>gamename wrote:

>>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; }

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.

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

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

[gamename]

On Mar 16, 8:39 pm, Thad Smith <[e-mail]:

gamename wrote:

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.

--
Thad

Thanks Thad. That's a good start.

[gamename]

On Mar 17, 2:59 pm, "goose" <[e-mail]:

On Mar 17, 7:53 am, Ian Collins <[e-mail]:

Jack Klein wrote:

On Sat, 17 Mar 2007 11:30:59 +1300, Ian Collins <[e-mail]>
wrote in comp.lang.c:

>>gamename wrote:

>>>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; }

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.

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]

gamename wrote:

>
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.

--
Ian Collins.

[gamename]

On Mar 18, 12:35 pm, Ian Collins <[e-mail]:

gamename wrote:

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.

--
Ian Collins.

Will do. Thanks.

-T