Extreme Programming - Using CPPUNIT_ASSERT in setUp and tearDown function

Author

Using CPPUNIT_ASSERT in setUp and tearDown function

Louis-Alexandre Berthier

2004-04-22, 4:35 pm

Hello,

When a CPPUNIT_ASSERT fails inside a regular test case, the test
results show the failure and give the file and line number. However,
when a CPPUNIT_ASSERT fails inside setUp or tearDown, it does not give
the file and line number (it just says setUp failed or something like
that).

I would like to have the same kind of information (file, line) even if
the CPPUNIT_ASSERT fails inside setUp or tearDown... Is this possible?
I tried with exceptions but it did not work. I am now using
std::assert in setUp and tearDown but this is bad because the whole
test process is obliterated when the std::assert fails (but at least I
get the file and line).

Any insight would be appreciated,
Louis-Alexandre

Phlip

2004-04-22, 6:35 pm

Louis-Alexandre Berthier wrote:

> When a CPPUNIT_ASSERT fails inside a regular test case, the test
> results show the failure and give the file and line number. However,
> when a CPPUNIT_ASSERT fails inside setUp or tearDown, it does not give
> the file and line number (it just says setUp failed or something like
> that).

My lite CppUnit clone performs correctly here:

http://www.xpsd.org/cgi-bin/wiki?NanoCppUnit

You could just go into your source and fix it. However...

> I would like to have the same kind of information (file, line) even if
> the CPPUNIT_ASSERT fails inside setUp or tearDown... Is this possible?
> I tried with exceptions but it did not work. I am now using
> std::assert in setUp and tearDown but this is bad because the whole
> test process is obliterated when the std::assert fails (but at least I
> get the file and line).

At failure time, if you predicted the failure, you should closely inspect
that the failure is what you expected.

http://flea.sourceforge.net/TDD_in_a_nut_shell.pdf

Because you should not put failures inside setUp() or tearDown() to create
new features, these are perforce unexpected failures. Hit <Undo> until the
code is back to the last state where all tests passed, and try again.

Many *Unit features "coddle" errors, such as presenting lists of them. Many
project situations need this high bandwidth of information. But raw TDD
depends on minimal code changes that reinforce your mental model of the
code's state. An unexpected error, regardless of its line number, is cause
to back off and reevaluate the situation.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Te...tUserInterfaces

Louis-Alexandre Berthier

2004-04-23, 10:38 am

"Phlip" <phlip_cpp@yahoo.com> wrote in message news:<YFWhc.701$E53.17@newssvr16.news.prodigy.com>...

> My lite CppUnit clone performs correctly here:
>
> http://www.xpsd.org/cgi-bin/wiki?NanoCppUnit

Thanks for the link, I'll go take a look. I thought about fixing the
source, but I was reluctant to do so because I would prefer to use the
"standard" CppUnit.

> Because you should not put failures inside setUp() or tearDown() to create
> new features, these are perforce unexpected failures.

I don't know if this is the right approach, but personally I see setUp
and tearDown as mere containers for duplicated code that would appear
at the top and bottom of every test method. Of course, they should not
contain "expected" failures, but on the other hand if the setUp is
fairly complex, it could fail for many different reasons (cannot read
file, server not available, etc.), and it is useful to obtain the
file/line information.

Thank you Phlip for your answer.
Louis-Alexandre

Sponsored Links