Re: [Cppunit-devel] templatized assertions

[Baptiste L. <gai...@fr...>]

Quoting "Steve M. Robbins" <ste...@vi...>:

> 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?
  The == operator seems like something that could be in the traits to.
  I'm not very good at naming stuff in english, but I would prefer a name that 
show that its not about assertion (the assertion is not done there), but 
converting the object to a string, and testing object for equality.

> 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.
  My though too.

> ... unless folks are using the class functions CppUnit::TestAssert::
> TestImplementation(), etc directly.  Do you?  What is the advantage of
> doing that?
  See Dolores Scott mail. I only have very few idea why someone would not rely 
on the assert:
  1) Somewhere there are some include of C assert, which override our assert 
macro... I'm still trying to find a work around that one. Suggestions are 
welcome.
  2) Don't want to use macro despite their usefulness
  3) Copied the example (which for unknown reason use assertImplementation). 
That one can be twisted around by implementing it in the TestCase class, and 
marking it as "deprecated" for later removal.

  I use macro because they provide location information. I'm still dreaming of 
having a stack trace ;-) 

> 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".
  I often also have the problem with the assertLongEqual which I write 
assertLongEquals. Fortunately it ends with compiler error...

> 
> 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.
  I would rather remove the existing assertEquals method which have "the" 
intuitive name. I don't like twisting around when its not needed.

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

If you look at the source you have:
/** A set of macros which allow us to get the line number
 * and file name at the point of an error.
 * Just goes to show that preprocessors do have some
 * redeeming qualities.
 */
#define CPPUNIT_SOURCEANNOTATION
  
#ifdef CPPUNIT_SOURCEANNOTATION
...

Which means if you removed the define, you must use the implementation 
(TestAssert).


---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French