By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,650 Members | 1,823 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,650 IT Pros & Developers. It's quick & easy.

Unit Testing With Function Mocking

P: n/a
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

Mar 16 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a

"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

Mar 16 '07 #2

P: n/a
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.
Mar 16 '07 #3

P: n/a
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
Mar 17 '07 #4

P: n/a
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
Mar 17 '07 #5

P: n/a
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.
Mar 17 '07 #6

P: n/a
On Mar 17, 7:53 am, Ian Collins <ian-n...@hotmail.comwrote:
Jack Klein wrote:
On Sat, 17 Mar 2007 11:30:59 +1300, Ian Collins <ian-n...@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.
If thats the case, then
#define printf (void)

should do the job without trampling all over the standard
library.
Mar 17 '07 #7

P: n/a
On Mar 16, 8:39 pm, Thad Smith <ThadSm...@acm.orgwrote:
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.

Mar 18 '07 #8

P: n/a
On Mar 17, 2:59 pm, "goose" <r...@webmail.co.zawrote:
On Mar 17, 7:53 am, Ian Collins <ian-n...@hotmail.comwrote:
Jack Klein wrote:
On Sat, 17 Mar 2007 11:30:59 +1300, Ian Collins <ian-n...@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.

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

Mar 18 '07 #9

P: n/a
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.
Mar 18 '07 #10

P: n/a
On Mar 18, 12:35 pm, Ian Collins <ian-n...@hotmail.comwrote:
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

Mar 19 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.