cppunit-devel — CppUnit Developer Mailing List

Re: [Cppunit-devel] Test result output (was: news features...)

[Duane M. <dua...@ma...>]

--- At Fri, 5 Oct 2001 17:26:56 +0200, Baptiste Lepilleur wrote:

>> 
>> There is a problem with missing itoa() (not only) on Linux, gcc
>> version
>> 2.95.2. I have attached a fix.
>
>  Thanks, I'll include that this evening. The baka I am completly forgot to 
>check if itoa was ANSI (aren't an ANSI equivalent anyway ?)

itoa() is most certainly not ANSI and there is no ANSI equivalent.

>-  return ::itoa( value, buffer, 10 );
>+  ::sprintf( buffer, "%d", value );

While this replacement is ANSI, its not really in keeping with the rest
of the code style. The rest of the code is largely C++ standard library.
Therefore the replacement should be something like the toString()
function in assertionTraits<>.

Maybe that function should be brought out entirely and converted to a
toString template function instead:

template <T>
std::string toString( const T& x )
{
    OStringStream ost;
    ost << x;
    return ost.str();
}

..Duane

Re: [Cppunit-devel] Test result output (was: news features...)

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

Quoting Volker Boerchers <vbo...@te...>:

> On Fri, 5 Oct 2001, Baptiste Lepilleur wrote:
> 
[...] 
> I wanted the following features:
>  - for every test method the name of the test was printed to STDOUT
>    either "passed", "failed" or "error".
>  - after execution of every single Test: print the name of the test
>    method and the execution time for the test to STDERR.
>    (That way we could mis-use the Unittests for performance checks)
>  - after each suite print either "--- suite: failed ---" or
>    "--- suite: success ---" goes to STDOUT.
>  - a more detailed summary of the suite is printed to STDERR.

  Easier, but not everything can be done. Some stuff I have in my head is to 
split in two:
  - a TextTestListener which report progress with the dot.
  - a TextTestResultOutputter which output the test result (list failure 
details).

  In your case, you might as well go ahead and write your one 
VerboseTextTestListener which output test name and status. You can compute the 
test execution time by intercepting startTest() and endTest() in the 
TestListener.
  For suite status report, not much help. There still isn't anything called 
when a suite is started/finished. Might be added in the future, though it would 
probably be a different Listener (TestSuiteListener ?).
  For the detailed log, you subclassing TextTestResultOutputter to get what you 
want.

> That way it was easy to get both, a compact log e.g. for a daily
> build,
> and a verbose log (first on STDOUT, the latter on STDERR).
> 
> Additionally every failure and error is printed in the same format that
> is
> used by g++. When i run the compile like that
> 
>   make && ./MyClassTest
> 
> from my IDE (emacs) I can use the editor's parser to get to the 
> location of test-errors using 'next-error'.

  Now, there is a funny thing. No later than this morning, I was thinking that 
I could add a "post build step" that would do myapp -selftest, and exits after 
running the test and reporting the error in VC++ format (slighty different from 
g++).

  The format I had in my head was (sketch):
file (line) :
test name (failure type)
(multiline-)message

Statistics

  That would be another Outputter (CompilerTestResultOutputter (base class), 
GccTestResultOutputter and MsvcTestResultOutputter ?)

> And - an essential for batch processing - the TextTestRunner returned
> an
> exit code that was translated in an exit code of the program signaling
> error or success.

  How about wasSucess() ?

> I hope it will be easier to implement such a thing after your changes.
  Easier, but there still works to be done. The heavy refactoring done on 
TextTestResult makes it easier to customize a particular part, but further 
refactoring it still needed to reach Nirvana.

> > Somebody on the Unix side should check that everything build
> correctly. 115
> > Unit tests should be running.

  Are all the 115 unit tests running (e.g. did I forgot to add a file in the 
MakeFile ?)

> 
> There is a problem with missing itoa() (not only) on Linux, gcc
> version
> 2.95.2. I have attached a fix.

  Thanks, I'll include that this evening. The baka I am completly forgot to 
check if itoa was ANSI (aren't an ANSI equivalent anyway ?)

  Baptiste.

> 
> Regards,
> Volker
> -- 
> Volker Boerchers <vbo...@te...>
> System Engineer
> TECON Systems AG, Perlengraben 2, 50676 Köln, http://www.tecon.de
> Tel: +49-221-92007-55, Fax: +49-221-92007-77
> 

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

Re: [Cppunit-devel] news features...

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

On Fri, Oct 05, 2001 at 04:01:13PM +0200, Volker Boerchers wrote:


> Additionally every failure and error is printed in the same format that is
> used by g++. When i run the compile like that
> 
>   make && ./MyClassTest
> 
> from my IDE (emacs) I can use the editor's parser to get to the 
> location of test-errors using 'next-error'.

Yes!!  This is *very* convenient, and I ended up doing the same thing
locally.  :-)

I really want to re-work the test-running code.  I posted some initial
thoughts back in June or July.  I'm planning to re-work some of them
into a proposal in the near future.

-Steve


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

Re: [Cppunit-devel] COM testing

[<ms...@te...>]

Jean-Baptiste,

thanks for the help and your suggestions.

I will go through your pointers and report if I successfully implement it.

I have to discuss the testing of the COM interface from C++ apps (my
developers asked it arguing that the runtime behaviour
is different and I obviously need to clarify this point).

Have a nice week end,

Marc




Baptiste Lepilleur <gai...@fr...>@lists.sourceforge.net on 05.10.2001
14:50:10

Sent by:  cpp...@li...


To:   ms...@te...
cc:   cpp...@li...

Subject:  Re: [Cppunit-devel] COM testing


Quoting ms...@te...:

>
> Another issue is how to write VB applications to test COM Components
> and
> still rely on CppUnit?
>
> Thanks,
>
> M

  Well, If I sum up you want:
  - test the COM interface with CppUnit
  - test the COM interface from VB
  - test the C++ object used to implement the interface with CppUnit (?)

  I don't have much experience with COM, and I never wrote any test for a
COM
object. All I can give you is pointers:

  Check the extreme progamming mailing list
(http://groups.yahoo.com/group/extremeprogramming), there was two recents
thread that might be of interest for you: XP & COM (started on 28/09), and,
VB
UNIT.

  There is also a new article on Martin Fowler page (
http://martinfowler.com/)
discussing Continuous Integration with C++ and COM.

  If I remember what I read, they basicaly advice to unit test the C++
object
hiding behind the COM interface independently from the COM interface.

  Also, I think that generating an MFC wrapper for the COM interface
(that's
what you're doing, right ?) may lead to some maintenance trouble if you
evolve
the interface (you have to regenerate a wrapper by hand, and it won't allow
for
the same class name if I remember from my past experience). The alternative
to
MFC wrapper if I remember is to use a pure abstract class that is generated
from the interface definition, and the helper (ATL library?) to use it.
This
might be better because you get compilation break if the interface change,
and
you don't have to manually update the wrapper. On the other hand, it's
probably
harder to use.

  One thing I don't get though, if you are using VB UNIT (available at
http://www.xprogramming.com/software.htm) to test the COM interface, why to
you
also want to test them with C++ (which would lead to double maintenance of
tests) ?

  Baptiste.


>
>
>
>
> ms...@te...@lists.sourceforge.net on 05.10.2001 12:07:51
>
> Sent by:  cpp...@li...
>
>
> To:   cpp...@li...
> cc:
>
> Subject:  Re: [Cppunit-devel] COM testing
>
>
>
> Thanks for your reply Jean Baptiste,
>
> To write test cases that are testing our COM components I'm using the
> MSDEV
> Class Wizard to generate the helper classes.
>
> CppUnit is still the framework that handle test creation, execution
> etc...
>
> The question is in fact : Do you have any recommendations or
> alternatives
> to work this ?
>
> Regards,
>
> Marc
>
>
>
>
>
>
> Baptiste Lepilleur <gai...@fr...>@lists.sourceforge.net on
> 05.10.2001
> 11:43:13
>
> Sent by:  cpp...@li...
>
>
> To:   ms...@te...
> cc:   cpp...@li...
>
> Subject:  Re: [Cppunit-devel] COM testing
>
>
> Quoting ms...@te...:
>
> > Hi,
> >
> > I'm currently using cppunit against C++ code, and was wondering if
> you
> > already think about a solution to
> > test COM code.
>
>   Can you precise your question ? Are you asking if somebody has
> already
> wrote
> some helper class for testing COM, or are you experiencing problem
> running
> your
> COM test case with CppUnit ?
>
>   Baptiste.
>
> > Thanks for your help,
> >
> > Marc


---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French
_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

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

Re: [Cppunit-devel] news features...

[Volker B. <vbo...@te...>]

On Fri, 5 Oct 2001, Baptiste Lepilleur wrote:

> A basic XML output has been added (I haven't tested it against XML softwa=
re
> yet, but the unit test say it's ok. So if I didn't mess up with the forma=
t
> it should be ok).

great to hear there's progress on the output front. Some months ago (when
i didn't knew the new CppUnit) i started to add some convenient features
to the output but found it very difficult to change something. (And i
ended in rewriting a lot of TextTestRunner, TestResult and the Decorateur
completely...)

I wanted the following features:
 - for every test method the name of the test was printed to STDOUT
   either "passed", "failed" or "error".
 - after execution of every single Test: print the name of the test
   method and the execution time for the test to STDERR.
   (That way we could mis-use the Unittests for performance checks)
 - after each suite print either "--- suite: failed ---" or
   "--- suite: success ---" goes to STDOUT.
 - a more detailed summary of the suite is printed to STDERR.

That way it was easy to get both, a compact log e.g. for a daily build,
and a verbose log (first on STDOUT, the latter on STDERR).

Additionally every failure and error is printed in the same format that is
used by g++. When i run the compile like that

  make && ./MyClassTest

from my IDE (emacs) I can use the editor's parser to get to the=20
location of test-errors using 'next-error'.

And - an essential for batch processing - the TextTestRunner returned an
exit code that was translated in an exit code of the program signaling
error or success.

I hope it will be easier to implement such a thing after your changes.

> Somebody on the Unix side should check that everything build correctly. 1=
15
> Unit tests should be running.

There is a problem with missing itoa() (not only) on Linux, gcc version
2.95.2. I have attached a fix.

Regards,
Volker
--=20
Volker Boerchers <vbo...@te...>
System Engineer
TECON Systems AG, Perlengraben 2, 50676 K=F6ln, http://www.tecon.de
Tel: +49-221-92007-55, Fax: +49-221-92007-77

Re: [Cppunit-devel] COM testing

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

Quoting ms...@te...:

> 
> Another issue is how to write VB applications to test COM Components
> and
> still rely on CppUnit?
> 
> Thanks,
> 
> M

  Well, If I sum up you want:
  - test the COM interface with CppUnit
  - test the COM interface from VB
  - test the C++ object used to implement the interface with CppUnit (?)

  I don't have much experience with COM, and I never wrote any test for a COM 
object. All I can give you is pointers:

  Check the extreme progamming mailing list 
(http://groups.yahoo.com/group/extremeprogramming), there was two recents 
thread that might be of interest for you: XP & COM (started on 28/09), and, VB 
UNIT.

  There is also a new article on Martin Fowler page (http://martinfowler.com/) 
discussing Continuous Integration with C++ and COM.  

  If I remember what I read, they basicaly advice to unit test the C++ object 
hiding behind the COM interface independently from the COM interface. 

  Also, I think that generating an MFC wrapper for the COM interface (that's 
what you're doing, right ?) may lead to some maintenance trouble if you evolve 
the interface (you have to regenerate a wrapper by hand, and it won't allow for 
the same class name if I remember from my past experience). The alternative to 
MFC wrapper if I remember is to use a pure abstract class that is generated 
from the interface definition, and the helper (ATL library?) to use it. This 
might be better because you get compilation break if the interface change, and 
you don't have to manually update the wrapper. On the other hand, it's probably 
harder to use.

  One thing I don't get though, if you are using VB UNIT (available at 
http://www.xprogramming.com/software.htm) to test the COM interface, why to you 
also want to test them with C++ (which would lead to double maintenance of 
tests) ? 

  Baptiste.


> 
> 
> 
> 
> ms...@te...@lists.sourceforge.net on 05.10.2001 12:07:51
> 
> Sent by:  cpp...@li...
> 
> 
> To:   cpp...@li...
> cc:
> 
> Subject:  Re: [Cppunit-devel] COM testing
> 
> 
> 
> Thanks for your reply Jean Baptiste,
> 
> To write test cases that are testing our COM components I'm using the
> MSDEV
> Class Wizard to generate the helper classes.
> 
> CppUnit is still the framework that handle test creation, execution
> etc...
> 
> The question is in fact : Do you have any recommendations or
> alternatives
> to work this ?
> 
> Regards,
> 
> Marc
> 
> 
> 
> 
> 
> 
> Baptiste Lepilleur <gai...@fr...>@lists.sourceforge.net on
> 05.10.2001
> 11:43:13
> 
> Sent by:  cpp...@li...
> 
> 
> To:   ms...@te...
> cc:   cpp...@li...
> 
> Subject:  Re: [Cppunit-devel] COM testing
> 
> 
> Quoting ms...@te...:
> 
> > Hi,
> >
> > I'm currently using cppunit against C++ code, and was wondering if
> you
> > already think about a solution to
> > test COM code.
> 
>   Can you precise your question ? Are you asking if somebody has
> already
> wrote
> some helper class for testing COM, or are you experiencing problem
> running
> your
> COM test case with CppUnit ?
> 
>   Baptiste.
> 
> > Thanks for your help,
> >
> > Marc


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

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

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

    I've been thinking about all our discussion about ASSERT_EQUAL and others 
assertion. I've come to the following conclusion:

    - CppUnit can not provide an ASSERT_EQUAL that satify everybody
    - CppUnit users need to create custome assertion (checking that two XML 
strings are identical for example ;-) )

    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
    
    I won't discuss (1) now since it is long winded discussed, with little 
value at the end. I'll tackle (2) right now which offer the most value for us.

    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)

    Introduce a new macro:
    #define CPPUNIT_SOURCELINE() CppUnit::SourceLine( __FILE__, __LINE__ )

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

    (That last one is not well refined yet, but it would be something like:

    void fail( std::string message, 
               SourceLine location = SourceLine() );
    void failIf( bool shouldFail, 
                 std::string message, 
                 SourceLine location = SourceLine() );
    void failNotEqual( std::string expected, 
                       std::string actual, 
                       SourceLine location = SourceLine(),
                       std::string additionalMessage ="" );
            // additionalMessage is a message that is append after the 
            // 'expect ... but was ...'. I noticed that it is really helpful
            // to have a precise report indicating why both are not equals. See
            // the CPPUNITTEST_ASSERT_XML macro used to compare two XML string
            // for example.
    void failNotEqual( bool shouldFail,
                       std::string expected, 
                       std::string actual, 
                       SourceLine location = SourceLine(),
                       std::string additionalMessage ="" );

    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 ?

   Baptiste.

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

Re: [Cppunit-devel] COM testing

[<ms...@te...>]

Another issue is how to write VB applications to test COM Components and
still rely on CppUnit?

Thanks,

M




ms...@te...@lists.sourceforge.net on 05.10.2001 12:07:51

Sent by:  cpp...@li...


To:   cpp...@li...
cc:

Subject:  Re: [Cppunit-devel] COM testing



Thanks for your reply Jean Baptiste,

To write test cases that are testing our COM components I'm using the MSDEV
Class Wizard to generate the helper classes.

CppUnit is still the framework that handle test creation, execution etc...

The question is in fact : Do you have any recommendations or alternatives
to work this ?

Regards,

Marc






Baptiste Lepilleur <gai...@fr...>@lists.sourceforge.net on 05.10.2001
11:43:13

Sent by:  cpp...@li...


To:   ms...@te...
cc:   cpp...@li...

Subject:  Re: [Cppunit-devel] COM testing


Quoting ms...@te...:

> Hi,
>
> I'm currently using cppunit against C++ code, and was wondering if you
> already think about a solution to
> test COM code.

  Can you precise your question ? Are you asking if somebody has already
wrote
some helper class for testing COM, or are you experiencing problem running
your
COM test case with CppUnit ?

  Baptiste.

> Thanks for your help,
>
> Marc

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

_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel




_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] COM testing

[<ms...@te...>]

Thanks for your reply Jean Baptiste,

To write test cases that are testing our COM components I'm using the MSDEV
Class Wizard to generate the helper classes.

CppUnit is still the framework that handle test creation, execution etc...

The question is in fact : Do you have any recommendations or alternatives
to work this ?

Regards,

Marc






Baptiste Lepilleur <gai...@fr...>@lists.sourceforge.net on 05.10.2001
11:43:13

Sent by:  cpp...@li...


To:   ms...@te...
cc:   cpp...@li...

Subject:  Re: [Cppunit-devel] COM testing


Quoting ms...@te...:

> Hi,
>
> I'm currently using cppunit against C++ code, and was wondering if you
> already think about a solution to
> test COM code.

  Can you precise your question ? Are you asking if somebody has already
wrote
some helper class for testing COM, or are you experiencing problem running
your
COM test case with CppUnit ?

  Baptiste.

> Thanks for your help,
>
> Marc

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

_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] COM testing

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

Quoting ms...@te...:

> Hi,
> 
> I'm currently using cppunit against C++ code, and was wondering if you
> already think about a solution to
> test COM code.

  Can you precise your question ? Are you asking if somebody has already wrote 
some helper class for testing COM, or are you experiencing problem running your 
COM test case with CppUnit ?

  Baptiste.

> Thanks for your help,
> 
> Marc

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

[Cppunit-devel] Removing TestRegistry...

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

    I intend to remove TestRegistry from CppUnit since it has been replaced 
with TestFactoryRegistry. The presence of both is confusing to user.

    Does anyone see a problem with that ?

    Baptiste.

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

Re: [Cppunit-devel] news features...

[Baptiste L. <bl...@cl...>]

A basic XML output has been added (I haven't tested it against XML software
yet, but the unit test say it's ok. So if I didn't mess up with the format
it should be ok).

Somebody on the Unix side should check that everything build correctly. 115
Unit tests should be running.

Baptiste.

----- Original Message -----
From: "Baptiste Lepilleur" <bl...@cl...>
To: "Cpp Unit Develpment Mailing List" <cpp...@li...>
Sent: Wednesday, October 03, 2001 11:14 PM
Subject: Re: [Cppunit-devel] news features...


>     3) add a flag to TestFailure distinguishing error/failure, retains
only
> one collection to store results (see other mail).
>
>     DONE ! Refactored much of TextTestResult on the way. It is now much
> easier to tune the output. Also some simplification were made: assertion
> failures and errors are in only one list (the kind of failure is indicated
> in parenthesis after the test name).
>
> ----- Original Message -----
> From: "Baptiste Lepilleur" <bl...@cl...>
> To: "Cpp Unit Develpment Mailing List"
<cpp...@li...>
> Sent: Tuesday, October 02, 2001 10:39 PM
> Subject: [Cppunit-devel] news features...
>
>
> >     1) CPPUNIT_TEST_EXCEPTION( method, ExceptionType)
> >     2) CPPUNIT_TEST_FAIL( method )
> >     4) CPPUNIT_TEST_SUITE_NAMED_REGISTRATION( TestFixtureType,
SuiteName )
> :
> > register the fixture's suite in a suite of the specified name.
> >
> >     Those features have been added. I would really appreciate if
somebody
> > could read and adjust the documentation of those macros. Somebody
> reviewing
> > the TestFactoryRegistry code would be nice too (probably the weirdest
> > life-cycle managment I've ever done).
> [...]
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

[Cppunit-devel] COM testing

[<ms...@te...>]

Hi,

I'm currently using cppunit against C++ code, and was wondering if you
already think about a solution to
test COM code.

Thanks for your help,

Marc

[Cppunit-devel] Partial answer: 2.3) Why does the test ExceptionTest.testAssignment failed in CppUnit test

[Phil T. <phi...@ts...>]

The implementation of the assignment operator for std::exception in
MSVCRT seems to be cause of the problem. Comment out the
SuperClass::operator= (other) call in Exception::operator=(Exception&)
and the test now passes.

Examination of MSVCRT disassembly yields some odd-looking (shortcut?)
behavior. It looks as though exception::operator=(exception&) resets
itself by calling its own destructor (memory is not freed) then calls
exception(exception&) to complete the assignment.

I can't progress the problem any further at this time but the
information above may be of some assistance.

Regards,
Phil

Re: [Cppunit-devel] news features...

[Baptiste L. <bl...@cl...>]

    3) add a flag to TestFailure distinguishing error/failure, retains only
one collection to store results (see other mail).

    DONE ! Refactored much of TextTestResult on the way. It is now much
easier to tune the output. Also some simplification were made: assertion
failures and errors are in only one list (the kind of failure is indicated
in parenthesis after the test name).

----- Original Message -----
From: "Baptiste Lepilleur" <bl...@cl...>
To: "Cpp Unit Develpment Mailing List" <cpp...@li...>
Sent: Tuesday, October 02, 2001 10:39 PM
Subject: [Cppunit-devel] news features...


>     1) CPPUNIT_TEST_EXCEPTION( method, ExceptionType)
>     2) CPPUNIT_TEST_FAIL( method )
>     4) CPPUNIT_TEST_SUITE_NAMED_REGISTRATION( TestFixtureType, SuiteName )
:
> register the fixture's suite in a suite of the specified name.
>
>     Those features have been added. I would really appreciate if somebody
> could read and adjust the documentation of those macros. Somebody
reviewing
> the TestFactoryRegistry code would be nice too (probably the weirdest
> life-cycle managment I've ever done).
[...]

---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

[Cppunit-devel] news features...

[Baptiste L. <bl...@cl...>]

    1) CPPUNIT_TEST_EXCEPTION( method, ExceptionType)
    2) CPPUNIT_TEST_FAIL( method )
    4) CPPUNIT_TEST_SUITE_NAMED_REGISTRATION( TestFixtureType, SuiteName ) :
register the fixture's suite in a suite of the specified name.

    Those features have been added. I would really appreciate if somebody
could read and adjust the documentation of those macros. Somebody reviewing
the TestFactoryRegistry code would be nice too (probably the weirdest
life-cycle managment I've ever done).

    CppUnit test suite hierarchy have been reworked to use
CPPUNIT_TEST_SUITE_NAMED_REGISTRATION (one of the problem of singleton is
that they are very difficult to test. So CppUnit itself use the things that
may break in the TestRegistry).

    You can found a screen-shot of the hiearchy there:
http://gaiacrtn.free.fr/cppunit/CppUniTestHierarchy-20011002.jpg

    Now, there still one little piece of TestFactoryRegistry that need work.
To create the suite hierarchy, we do (CppUnitTestSuite.cpp):

  CppUnit::TestFactoryRegistry &registry =
                      CppUnit::TestFactoryRegistry::getRegistry();


istry.registerFactory( 
      &CppUnit::TestFactoryRegistry::getRegistry( coreSuiteName() ) );
  registry.registerFactory( 
      &CppUnit::TestFactoryRegistry::getRegistry( helperSuiteName() ) );
    ...

    As you figured out, it would be nice to be able to do:
    registry.registerNamedRegistry( coreSuiteName() );
    registry.registerNamedRegistry( helperSuiteName() );

    What I need is a good name for the method. What this method does can be really confusing, so a good name would help. Here is what it does (well, wording it can be somewhat confusing too...):

    You have a TestFactoryRegistry that contains a list of TestFactory. Since a TestFactoryRegistry is a TestFactory, you can add a TestFactoryRegistry to another TestFactoryRegistry (what is done in the example).

    The method would retreive the registry of the specified name using TestFactory::getRegistry( name ), and regist
er that factory to its list of factory (using registerFactory).

    I would also need a macro name. The macro would work in the spirit of
CPPUNIT_TEST_SUITE_REGISTRATION:

    CPPUNIT_REGISTER_REGISTRY_SUITE_INTO( suiteToRegisterName, suiteName )
        // with some decorating, it would do:

stFactory::getRegistry( suiteName).registerNamedRegistry( suiteToRegisterNam
e )

    Any suggestions ?

    Baptiste.

Re: [Cppunit-devel] equality of const objects

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

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

> On Mon, Oct 01, 2001 at 12:45:40PM -0700, Duane Murphy wrote:
> 
> > I would also make the argument (FWIW) that const is all that is
> needed.
> > Comparison operators should not be mutating. (Caches are caches and
> > should be marked mutable.)
> 
> I happen to agree with you.  If it were my decision alone, I'd just
> leave things as-is and let the folks who can't compare const objects
> to suffer for their sins.  ;-)
> 
> 
> > This is also where you want to make the change for comparing
> equivalent
> > objects (not the same type). The change would be thus:
> > 
> >      template <class TExepect, TActual>
> >      void assertEquals( const TExepect & expected,
> >                         const TActual & actual, ... )
> 
> I'm fairly skeptical that we want to allow this.  
> 
> I seem to recall changing my local copy of CppUnit some months ago to
> allow assertEquals() on two different types.  And I seem to recall
> running into problems because the compiler likes to promote types
> and use implicit conversions and all the other good stuff.  
> Sorry to not be more specific at this point...

  Euhh, I don't get it. We can perfectly control implicit conversion by 
defining one argument constructor explicit. Implicit conversion of basic type 
is something I (we?) want (unsigned int => int..., const char * => 
std::string)... It would make the test much easier to read...

  If unwanted implicit conversion occurs, wouldn't that point out a 'bug' ? Or 
was the problem, the compiler raising conflict because many conversions were 
possible ?

  Baptiste.

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

Re: [Cppunit-devel] equality of const objects

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

Quoting Duane Murphy <du...@us...>:

> The problem with the above change to assertEquals is that it is
> embedded
> in a template class that also defines the toString operations on one
> type. This has to be solved also. 

  Indeed I'm more bothered with that problem than with the const issue (doesn't 
raise as often).

  With VC++, you need to write:
  std::string str( "123" );
  std::vector v;
  CPPUNIT_ASSERT_EQUAL( 3, int(str.length()) );
  CPPUNIT_ASSERT_EQUAL( std::string("123"), str );
  CPPUNIT_ASSERT_EQUAL( 0, int(v.size()) );

  Which I find make the test much harder to read than:
  CPPUNIT_ASSERT_EQUAL( 3, str.length() );
  CPPUNIT_ASSERT_EQUAL( "123", str );
  CPPUNIT_ASSERT_EQUAL( 0, v.size() );

> 
> A couple of suggestions:
> (1) seperate the class into two template classes
> (2) Dont use a template class just template functions
> (3) Use class template methods (I have the terminology wrong for
> sure).
> There may be a limitation with some compilers using this method.

  (3) is to be avoided if we have alternative. VC++ template method support is 
shacky (TestAssert used to be a class and the assertEquals template method 
caused Compiler-error).

  (2) I'm not sure. I think template class are more supported than template 
function by many compiler. Could any one confirm this ?

  (1) Separating the equality test from the string conversion is something I'm 
thinking about. Outputing a message containing an object has must more 
application than just equality assertion. Thanks to the extra info, we can just 
deduce what is wrong and we don't have to run the debugger. An object dump 
often provide a better view of the object than the one you get with the 
debugger.

  For example, we might want:
  CPPUNIT_DETAIL_ASSERT( date.isValid(), date );
  which would behave like a standard assertion, but also dump the specified 
object.

  Another example, I've a tools utility function that check if 2 unordered 
collections contains the same elements (they may not be at the same position in 
the collection):
  checkCollectionContainsIdenticalItems( expectedCollection, actualCollection, 
my_equal_predicate() );

  When it asserts, it does it with a message listing the expected item that 
were not in the actual collection, and those that should not be in the 
actualCollection. That function would use the string dump service but not 
the 'equality' service (depending of the context, the presence of an item can 
change: they must have the same 'key', or all their attributes need to be 
equals...)

  Well, the point is that the 'dump object to string' service has a much wider 
range of use than just ASSERT_EQUAL.

  Baptiste.

> 
> Anyhow, just some suggestions.
> 
> .Duane
> 
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 



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

Re: [Cppunit-devel] equality of const objects

[Duane M. <dua...@ma...>]

--- At Mon, 1 Oct 2001 16:32:52 -0400, Steve M. Robbins wrote:

>On Mon, Oct 01, 2001 at 12:45:40PM -0700, Duane Murphy wrote:
>
>> I would also make the argument (FWIW) that const is all that is needed.
>> Comparison operators should not be mutating. (Caches are caches and
>> should be marked mutable.)
>
>I happen to agree with you.  If it were my decision alone, I'd just
>leave things as-is and let the folks who can't compare const objects
>to suffer for their sins.  ;-)

In discussing this with our group, we will be removing the non-const
features from our version of the library. We feel that it is important to
enforce const equality tests. C++ gives us lots of power to do strange
and unusual things. We need all the help we can get to make sure we are
doing the right thing.

>> This is also where you want to make the change for comparing equivalent
>> objects (not the same type). The change would be thus:
>> 
>>      template <class TExepect, TActual>
>>      void assertEquals( const TExepect & expected,
>>                         const TActual & actual, ... )
>
>I'm fairly skeptical that we want to allow this.  
>
>I seem to recall changing my local copy of CppUnit some months ago to
>allow assertEquals() on two different types.  And I seem to recall
>running into problems because the compiler likes to promote types
>and use implicit conversions and all the other good stuff.  
>Sorry to not be more specific at this point...

You are of course correct. This is one of the places that concerns me
most in writing C++. Those conversions can magically make code do very
unexpected things.

>The question, in my mind, is: why are you comparing two different
>types for equality, anyway???
>
>There are two alternatives that come to mind:
>
>1. Construct an appropriate "expected" value to begin with.
>   If you claim the two types are "equivalent", then you should
>   be able to construct an appropriate object.  In the enum/int
>   example, use CPPUNIT_ASSERT_EQUAL( int(noErr), FunctionToTest() );

This turns out to be the best suggestion for my simple example.

>2. Make up your own comparison functions and use CPPUNIT_ASSERT.
>
>	bool my_equality_T1_T2( const T1& x, const T2& y ) { ... }
>
>	#define CPPUNIT_ASSERT_EQUALS_T1_T2(x,y) \
>		CPPUNIT_ASSERT( my_equality_T1_T2(x,y) )
>
>   I do this sort of thing all the time.  Not everything needs to be 
>   in the base library.

Thanks, this is a good suggestion!

Re: [Cppunit-devel] equality of const objects

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

On Mon, Oct 01, 2001 at 12:45:40PM -0700, Duane Murphy wrote:

> I would also make the argument (FWIW) that const is all that is needed.
> Comparison operators should not be mutating. (Caches are caches and
> should be marked mutable.)

I happen to agree with you.  If it were my decision alone, I'd just
leave things as-is and let the folks who can't compare const objects
to suffer for their sins.  ;-)


> This is also where you want to make the change for comparing equivalent
> objects (not the same type). The change would be thus:
> 
>      template <class TExepect, TActual>
>      void assertEquals( const TExepect & expected,
>                         const TActual & actual, ... )

I'm fairly skeptical that we want to allow this.  

I seem to recall changing my local copy of CppUnit some months ago to
allow assertEquals() on two different types.  And I seem to recall
running into problems because the compiler likes to promote types
and use implicit conversions and all the other good stuff.  
Sorry to not be more specific at this point...

The question, in my mind, is: why are you comparing two different
types for equality, anyway???

There are two alternatives that come to mind:

1. Construct an appropriate "expected" value to begin with.
   If you claim the two types are "equivalent", then you should
   be able to construct an appropriate object.  In the enum/int
   example, use CPPUNIT_ASSERT_EQUAL( int(noErr), FunctionToTest() );


2. Make up your own comparison functions and use CPPUNIT_ASSERT.

	bool my_equality_T1_T2( const T1& x, const T2& y ) { ... }

	#define CPPUNIT_ASSERT_EQUALS_T1_T2(x,y) \
		CPPUNIT_ASSERT( my_equality_T1_T2(x,y) )

   I do this sort of thing all the time.  Not everything needs to be 
   in the base library.


-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

Re: [Cppunit-devel] equality of const objects

[Duane M. <du...@us...>]

>
>Can't we have both?  What about 
>
>     template <class T>
>     void assertEquals( const T& expected,
>                        const T& actual, ... )
> 
>     template <class T>
>     void assertEquals( T& expected,
>                        T& actual, ... )
> 
>with the same implementation.
>[Ditto for the default assertion_traits template]
>
>I just tried this modification; the library builds and runs
>the test suite successfully.  Comments?

This is perfectly legal C++ (overloads by const). (If Forte doesnt
support this, how does it compile the C++ standard library; there are
several places where this overload is used.) 

I would also make the argument (FWIW) that const is all that is needed.
Comparison operators should not be mutating. (Caches are caches and
should be marked mutable.)

This is also where you want to make the change for comparing equivalent
objects (not the same type). The change would be thus:

     template <class TExepect, TActual>
     void assertEquals( const TExepect & expected,
                        const TActual & actual, ... )

The compiler will complain if the objects cannot be compared. I ran into
this problem with my tests. Consider:

enum
{
    noErr = 0,
    someErr = -100
};

int FunctionToTest();

..
CPPUNIT_ASSERT_EQUAL( noErr, FunctionToTest() );

This wont compile because noErr is an anonymous enum type and not an int.

The problem with the above change to assertEquals is that it is embedded
in a template class that also defines the toString operations on one
type. This has to be solved also. 

A couple of suggestions:
(1) seperate the class into two template classes
(2) Dont use a template class just template functions
(3) Use class template methods (I have the terminology wrong for sure).
There may be a limitation with some compilers using this method.

Anyhow, just some suggestions.

.Duane

Re: [Cppunit-devel] equality of const objects

[Stanley S. <su...@t-...>]

"Steve M. Robbins" wrote:

> Can't we have both?  What about
>
>      template <class T>
>      void assertEquals( const T& expected,
>                         const T& actual, ... )
>
>      template <class T>
>      void assertEquals( T& expected,
>                         T& actual, ... )
>
> with the same implementation.
> [Ditto for the default assertion_traits template]
>
> I just tried this modification; the library builds and runs
> the test suite successfully.  Comments?
>
> -Steve
>
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel

This will break on Sun's Forte 6, update 1 compiler, although it is perfectly
valid C++, according to both ISO and ANSI.  I hope it will be fixed in update 2.

--
Stanley M. Sutton   sms...@ie...           su...@t-...
TSurf Corporation - The gOcad Company -         http://www.t-surf.com
11011 Richmond Ave. Suite 350                   Houston TX 77042
Phone: (1) 713 787 0746 ext. 13                 Fax: (1) 713 787 0852
---------------------------------------------------------------------
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
                                      - Benjamin Franklin

Re: [Cppunit-devel] equality of const objects

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

On Tue, Sep 25, 2001 at 05:13:33PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:
> 
> > On Tue, Sep 25, 2001 at 02:56:55PM +0200, Baptiste Lepilleur wrote:
> > 
> > >   I'm not saying to change CppUnit as a whole. The only thing I want
> > >   to change is those part of CppUnit that would impose on the
> > >   "user" policy:
> > > 
> > >  struct assertion_traits 
> > >   {  
> > >       static bool equal( const T& x, const T& y )
> > > => change to 
> > >       static bool equal( T& x, T& y )
> > > 
> > >   and 
> > >     template <class T>
> > >     void assertEquals( const T& expected,
> > >                        const T& actual,
> > > => change to:
> > >     template <class T>
> > >     void assertEquals( T& expected,
> > >                        T& actual,
> > >  
> > >   The change is invisible for user that apply the "const" policy, and
> > allow 
> > > user who don't to use the assertEquals without having to do
> > const_cast.
> > 
> > Sorry Baptiste, I do not understand.  Why do you say that using const
> > references makes writing equal() black magic?  Can you give us a short
> > example of a class that is problematic for equal(const&,const&)?
> 
>    Example of assertion_traits for FileDependency:
> 
>       static bool equal( const FileDependency& x, const FileDependency& y )
>       {
>         return const_cast<FileDependency&>(x).equalsTo( 
> const_cast<FileDependency *>( &y ) );
>       }
> 
>       static std::string toString( const FileDependency& x )
>       {
>         return const_cast<FileDependency&>( x ).toString();
>       }
> 
>       The const_cast are the things I call "black magic".

I agree.  However, in my mind, this raises the question "why don't the
FileDependency methods equalsTo() and toString() have a const
qualifier on them?"

Yes, I understand: you don't want to impose policy on the user.
Fair enough.


>     template <class T>
>     void assertEquals( const T& expected,
>                        const T& actual, ... )
> 
> => change to :
>     template <class T>
>     void assertEquals( T expected,
>                        T actual, ... )
> 
>     This means that pass-by-value would be use instead of const reference. 
> Means that tested object should either have a copy constructor or be pointer.

It also implies a lot of useless copying if you're comparing lists,
n'est pas?  

Can't we have both?  What about 

     template <class T>
     void assertEquals( const T& expected,
                        const T& actual, ... )
 
     template <class T>
     void assertEquals( T& expected,
                        T& actual, ... )
 
with the same implementation.
[Ditto for the default assertion_traits template]

I just tried this modification; the library builds and runs
the test suite successfully.  Comments?

-Steve

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

Re: [Cppunit-devel] CppUnit 1.7.0

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

Hi all,

I was too lazy to announce it last night, but:

	1.6.1 is out!!



On Mon, Oct 01, 2001 at 08:11:34PM +0200, Baptiste Lepilleur wrote:
>     Hi Steve,
> 
>     I noticed you updated the version 1.7.0, so If I understood well, we're
> going to make the change for release 1.8.0 straight into the main trunc,
> right ?

Yes, exactly.

-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