Cppunit: Test functions and/or whole applications?

People talk a lot about unit tests, meaning single functions of the
code are tested and their outputs are compared to expected outputs.

But noone talks about testing a whole compiled application. For
example, I also want to check if my compiled command line tool app.exe
really prints out what it has to print out. (my app.exe is not
interactive)

Is there a framework that can do both? Testing single functions and
testing whole compiled applications? For my projectg, I want to do
both.

It should be possible to write a wrapper function that calls my
compiled program with system(). This wrapper function could then be
tested with Cppunit. Does that make sense? Or are Makefiles using diff
just the right thing to test a compiled app?

Thanks!

In article <c1e48b51.0408251739.478b6e39@posting.google.com>,
Markus Dehmann wrote:

> It should be possible to write a wrapper function that calls my
> compiled program with system(). This wrapper function could then be
> tested with Cppunit. Does that make sense? Or are Makefiles using diff
> just the right thing to test a compiled app?

I've been using such approach (diffs), but while application grows tests
becomes very hard to maintain. Single change in functionality causes a
lot of modifcations in several tests.

I've choosed another strategy: set up is done at low-level (several
inserts into database) and output from high-level is checked selectively
(example: if customer name is visible on the customer lists). Those
tests check connection between UI and application model.

More checks are done at lower (application model, unit tests) level -
they are easier to set-up and to check.

--
Regards, Darek Cieslak; +48 505-670-010;          cieslakd at gazeta.pl
http://xprogramming.prv.pl - ExtremeProgramming / TestDrivenDevelopment
Cartalia.com: +48 (022) 334-54-09 int. 121;         http://cartalia.com

markus.cl@gmx.de (Markus Dehmann) writes:

> It should be possible to write a wrapper function that calls my
> compiled program with system(). This wrapper function could then be
> tested with Cppunit. Does that make sense? Or are Makefiles using diff
> just the right thing to test a compiled app?

This looks like an acceptance test to me. Not that it matters, but just as a
point of reference.

Anyway, I would do this the simplest way that would get me meaninful
results. If capturing the output and doing a diff gives you enough
information, do that. If you need to process the output in some way to extra
ct
useful info, then write a wrapper to launch your app, capture the output,
process it and check the results.

OTOH, you can test your code directly if your main function just forwards
everything to a function called "doStuff", for example. You can then call
doStuff directly from your tests, rather than having to launch the app. This
is the way I would go for development tests.

HTH,

Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.

On 25 Aug 2004 18:39:27 -0700, markus.cl@gmx.de (Markus Dehmann)
wrote:

>People talk a lot about unit tests, meaning single functions of the
>code are tested and their outputs are compared to expected outputs.
>
>But noone talks about testing a whole compiled application. For
>example, I also want to check if my compiled command line tool app.exe
>really prints out what it has to print out. (my app.exe is not
>interactive)
>
>Is there a framework that can do both? Testing single functions and
>testing whole compiled applications? For my projectg, I want to do
>both.

Have you looked at FitNesse?  (www.fitnesse.org)  I wrote a fixture
for FitNesse some time ago named CommandLineFixture.  It was able to
monitor standard out and standard error and verify that the right
things got printed, etc.


-----
Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo