Re: [Cppunit-devel] templatized assertions

[Steve M. R. <ste...@vi...>]

On Thu, May 17, 2001 at 02:16:20PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:

> > On Wed, May 16, 2001 at 09:28:06PM +0200, Baptiste Lepilleur wrote:
> > > I would use a trait to add the object to the stream. The trait generic
> > > implementation would use '<<', but could be specialized when needed.
> > 
> > That sounds like a reasonable idea.  I'm not terribly experienced in
> > traits; what would be a good name for the function?  Some of CppUnit
> > already uses "toString", which seems reasonable enough, yes?
>   It looks good to me.

Okay.  I have defined a templated class named AssertionTraits, with 
exactly one member: toString.  Using a traits class for just one thing
seems like overkill to me.  What other things do you suppose might go
in there?  Is there a better name than AssertionTraits?

 
> > Actually: why does TestAssert need to be a class at all?  There are no
> > data members, so why not just make it a namespace with a bunch of
> > templatized functions?
>   The idea was to inherit that class when you wanted to use assertion. But this 
> is of no use since we use macro to capture source file & line number and those 
> macro are global.

That was my thinking: the assert macros are the interface, as far as I
know (but remember that I only started using CppUnit this week!), so
what they use as a back-end is irrelevant.  Global functions in a
TestAssert namespace should do just as well.

... unless folks are using the class functions CppUnit::TestAssert::
TestImplementation(), etc directly.  Do you?  What is the advantage of
doing that?

I discovered an annoyance with the current names.  As I mentioned the other
day, I'd like to have a generic "assert a ==  b" macro.  I tentatively
called it assertEqual.  The definition is as follows:

	#define assertEqual(expected,actual)\
	(CppUnit::TestAssert::assertEquals ((expected),\
	        (actual),__LINE__,__FILE__))

unfortunately, the name is too close to TestAssert::assertEquals, which
can also take two parameters (the last two have default values).  This
makes it way too easy (I've already done it once) to use assertEquals(x,y)
in the test case, and then wonder why the failure shows up at "unknown line".

If nobody is using the back-end functions, I'd solve this by just renaming
them.  Then, using assertEquals() would be a compile-time error.

Of course, the other way to solve it is to pick a sufficiently different
name for the new macro.  Suggestions welcome.

 
>   Using namespace should indeed solve the template member problem.
>   I can see the following impact:
>   - remove inheritance of TestAssert in TestCase
>   - update the sample to use assert macro instead of assertImplementation (I 
> wonder why it's doing that anyway)
> 
>   Removing inheritance would require people to explicitly use the namespace for 
> assertion if they disabled the assert macro. Anybody see a problem with that ?

I don't understand what you mean by "disabled the assert macro".  I don't see a
way for doing that.  Are you referring to folks directly using the TestAssert
member functions?
 
-S

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants