Re: [Cppunit-devel] Assertion, ASSERT_EQUAL & co...

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

Hey Baptiste,


On Fri, Oct 05, 2001 at 02:30:36PM +0200, Baptiste Lepilleur wrote:
 
>     So, the path I wish to take is:
>     1) propose a reasonable default ASSERT_EQUAL (to discuss later)
>     2) provide all the tools for user to easily implement a new assert macro

This sounds promising!


>     Here is the list of what a ASSERT macro typically do:
>     a) capture filename and line where the macro was expanded for easy 
> localisation of failure
>     b) throw an Exception if failure occurs. The Exception convey a message 
> describing the failure, and the location of the failure captured in (a).
> 
>     That means CppUnit should help the user with both step. At the current 
> time, it means relying on TestAssert::assertImplemention and a lot of passing 
> filename and line around as parameter.
> 
>     First I apply IntroduceParameterObject and create a SourceLine class that 
> contains the filename and the line, and a nice default constructor when those 
> are not available. Refactor all CppUnit to use SourceLine (Exception, 
> TestAssert)

I like this idea.


 
>     Introduce helper methods in TestAssert to factor out code that throw 
> exception for failure.

OK, but anything that is called an "assertion" should involve testing
a boolean value.  A function that unconditionally throws an exception
is not an assertion of anything, it is merely throwing an exception;
such a function should not live in TestAssert.  It could live in the
Exception class, perhaps.


> 
>     (That last one is not well refined yet, but it would be something like:
> 
>     void fail( std::string message, 
>                SourceLine location = SourceLine() );

This sounds like "throw exception unconditionally" ?


>     void failIf( bool shouldFail, 
>                  std::string message, 
>                  SourceLine location = SourceLine() );

This sounds like the replacement for the current "assertImplementation"?
If so, why not call it simply "assert"?


>     void failNotEqual( std::string expected, 
>                        std::string actual, 
>                        SourceLine location = SourceLine(),
>                        std::string additionalMessage ="" );
>
>     void failNotEqual( bool shouldFail,
>                        std::string expected, 
>                        std::string actual, 
>                        SourceLine location = SourceLine(),
>                        std::string additionalMessage ="" );

I don't get these two.  It seems like replacements for the current
"assertEquals", except that you've simply moved the equality testing
out of the assertion_traits and made it a parameter (of the second
function).

If that is the aim, then what is being provided to the library
user?  It is construction of the exception message.  So, how about
thinking up common message constructors that one can use with the
standard TestAssert::assert():

	std::string should_equal_message( string expected, string actual,
					  SourceLine location,
					  string additional )
        {
 	    return "Expected " + expected + " but got " ...
        }


 
>     Note that some of those function probably exist in TestAssert).
> 
>     The next step would be to move assertion code outside of TestAssert 
> (assertEquals...). TestAssert would provide service to report failed assertion, 
> but would not implement those assertions (and therefore making no choice about 
> how those assertion are implemented).
> 
>     This would leave the user with a very simple way to write new assertion 
> MACRO. For example:
> 
>    MYASSSERT_XML_EQUAL( expected, actual ) \
>        checkXmlEqual( expected, actual, CPPUNIT_SOURCELINE() );
> 
>    checkXmlEqual( std::string expected,
>                   std::string actual,
>                   SourceLine location )
>    {
>       if ( expected != actual ) // Whatever you want there
>         CppUnit::TestAssert( fail, expected, actual, location );
>    }
> 
>    I'll try to tackle the first part this evening (applying the 
> IntroduceParameteObject refactoring).
> 
>    Does the change to TestAssert sound good for you ?

I really like the idea of providing small building blocks for writing
custom assertions.  I think the building blocks should be very small
and very generic.  Having five nearly-the-same-but-slightly-different
methods leads to great confusion, at least in my mind.  I think we
should consider hard what building blocks the library should provide.

I also wonder whether "TestAssert" is the best namespace for it.

-Steve

P.S.  Also, think about backwards compatibility.  I know we are still
"pre-alpha" so I don't mind breaking it, but if it doesn't cost too
much, I'm in favour of being compatible.  If nothing else, make notes
about what is getting broken.

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