cppunit-devel — CppUnit Developer Mailing List

Re: [Cppunit-devel] config.h changes committed

[Bastiaan B. <bas...@li...>]

"Steve M. Robbins" wrote:

> On Sun, Jun 17, 2001 at 10:20:16PM +0200, Bastiaan Bakker wrote:
>
> > I finally comitted the config.h changes I proposed last week.
>
> Yay!
>
> > * use  autoconf 2.40 or higher to rebuild aclocal.m4, because the
> > AC_CREATE_PREFIX_CONFIG_H macro needs the AS_DIRNAME macro.
>
> I expect you meant "2.50" ?

The docs somewhere stated that AS_DIRNAME has been included in 2.40.
Don't know whether that's a public release or not, or that it was a
typo. I'm using 2.50 myself.

>
>
>
> > * include <cppunit/Portability.h> instead of <cppunit/config.h>
>
> Okay, but ... did you neglect to cvs add Portability.h?
> [And config-xxx.h?]
>

:-( Yes, I forgot to commit them, grr. They've been added now.

Thanks,

Bastiaan

Re: [Cppunit-devel] config.h changes committed

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

On Sun, Jun 17, 2001 at 10:20:16PM +0200, Bastiaan Bakker wrote:

> I finally comitted the config.h changes I proposed last week. 

Yay!


> * use  autoconf 2.40 or higher to rebuild aclocal.m4, because the
> AC_CREATE_PREFIX_CONFIG_H macro needs the AS_DIRNAME macro.

I expect you meant "2.50" ?

 
> * include <cppunit/Portability.h> instead of <cppunit/config.h>

Okay, but ... did you neglect to cvs add Portability.h?
[And config-xxx.h?]

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

[Cppunit-devel] config.h changes committed

[Bastiaan B. <bas...@li...>]

Hi,

I finally comitted the config.h changes I proposed last week. They have
some consequences:

* use  autoconf 2.40 or higher to rebuild aclocal.m4, because the
AC_CREATE_PREFIX_CONFIG_H macro needs the AS_DIRNAME macro.

* don't HAVE_BLA, etc. macro's anymore, use CPPUNIT_HAVE_BLA instead.

* include <cppunit/Portability.h> instead of <cppunit/config.h>

* don't use platform specific macros (i.e. _MSC_VER) in common source
code anymore. Instead 'fix' it in Portability.h or create a CPPUNIT_
macro descibing the non portable feature.

* if you add a test to ./configure.in add the corressponding #define to
cppunit/config-msvc6.h and cppnuit/config-bcb5.h. I you don't know the
correct value for these platforms add and #error with some useful info
for the platform maintainer.

Cheers,

Bastiaan

[Cppunit-devel] Functionnal testing framework ?

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

    I know this might be a bit of topics, but does any of you know of a
functionnal testing framework (for C++, but other would still be
interresting for ideas) ?

    Main differences I see with unit testing is:
    - facilities provided to read test from file (csv file(Excel), xml, flat
file...) and initialize "business objects",
    - facilities provided to track the evolution of test (regression,
progression...),
    - facilities provided to report a bit more than a simple failure
(something akin to an expected/actual result, but probably more advanced).

    Note that I'm not looking for something to test GUI stuff, it's pure
server-side business process there. I'd like to have something akin to
cppunit.

    Thanks in advance,
    Baptiste.
---
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] Going into production... Any advices?

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

    Well, I finally managed to get some of my way and we'll be using
automated unit testing for a coming development at work.

   Here is what I plan to do to "survive" cppunit evolution:

   - only use HelperMacros and TestCase: macros can always be rewritten in
the worst case, and they provide isolation from the framework.
   - use a "proxy header": this header will include need cppunit headers.
This provides isolation from the actual location of those header.
   - not using assertEquals traits (though I would really like to be able,
it might still evolve)

   I believe I should be safe enough with those. Does somebody else have any
experience of using CppUnit in production environment ?

   Thanks,
   Baptiste.
---
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).

Re: [Cppunit-devel] include directory clean-up

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

Well, now for the last part ;-)

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Thursday, June 14, 2001 5:16 PM
Subject: Re: [Cppunit-devel] include directory clean-up


> On Thu, Jun 14, 2001 at 04:39:41PM +0200, Baptiste Lepilleur wrote:
> >   textui/: text based TestRunner
> >     TestRunner.h  (within the CppUnit::TextUi namespace, was
TextTestRunner.h)
> >   mfcui/: MFC based TestRunner
> >     TestRunner.h  (within the CppUnit::MfcUi namsepace, was
> > msvc6/TestRunner/TestRunner.h )
>
> Here, the directory structure is intended to mirror the namespace
> structure, right?  I wonder what is intended to be in the
> CppUnit::<UI> namespace.  Currently, there is only TestRunner; are
> more classes envisioned?  If not, we'd be creating multiple <UI>
> namespaces with a single member each.  That doesn't sound right.  Why
> not create a TestRunner base class, with specializations for each UI?
   Well, for the TextUi I can't see anymore classes coming. We are limited
by portability which means no RTTI and therefore no test hierarchy browsing
(we could still add a "dump" test hierarchy option).
   For the MfcUi, I have restricted the "published" part to the strict
minimum because the other parts are evolving a lot. But ultimately, we
should reach a well factored and solid TestRunner that allow subclassing.
The dialog, and the models would be published and the user could subclass
them.
   For example, I have planned a "detail" feature, that show the detail
about the selected failure in the list. For a basic "Exception" failure, you
would just have larger text fields to read them properly. For the
"NotEqualException", you would have two text fields to compare the
"expected" and "actual" value (with a nice diff option of course ;-) ).
  When the user extends the framework by subclassing Exception, the user
should be able to provide a new "detail" view for that exception. This is a
very far goal, but one none the less.
  Closer goal, would be to be able to subclass the TestRunnerModel (being
worked on, it is a model that contains the list of test failure reported in
the list), so the user could add functionnalities, such as the time is took
for each test to run, write a duplicate of the failure to a file...
  It's going on slowly (I'm not a MFC expert), but certainly.

  As a alternative for the directories, we could have:
  include/
     cppunit/
     cppunitui/
        mfc/
        text/

  I think I like that one better,
  Baptiste.

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

Re: [Cppunit-devel] include directory clean-up

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

> Quoting "Steve M. Robbins" <ste...@vi...>:
>
> > On Thu, Jun 14, 2001 at 04:39:41PM +0200, Baptiste Lepilleur wrote:
> > I think that drafting an outline of the library will help in
> > organizing the directory structure (and possibly the namespace
> > structure).  Questions that I have, for example: what is the
> > difference between an "extension" and a "helper"?  What is the "core"
> > of the framework, anyway?
>
>   I'll try to define those as I perceive them:
>
> core: it is the minimal(not really) set of classes for unit testing. It
> provides the following functionnalities:
>  - writing (TestAssert) and running test (Test).
>  - report test failure
> (TestCase,TestResult,Exception,NotEqualException,TestListener)
>  - organize test in suite (TestSuite)
>  I would also include:
>  - being able to write a test in a single class method (TestCaller)
>  - should be extensible
>
> extensions: they extends the functionnalities provided by the framework.
> helper(s?): they don't add functionnalities but make using existing
> functionnalities easier.
  I admit the difference can be tricky. Does the TestFactoryRegistry add to
the core functionnality ? I would say no: you can't do anymore than you were
doing. It only make it easier: you don't have to create class for each
suite, remember to add the new suite in the suite... You even lose
extensibility: the suite instantiated will all be TestSuite. You lose some
portability (it use a static variable and it has been reported that some
compiler on embedded do not support this well).
  The macros case is a bit easier: they help you implement your everyday
test case.
  The TestSuiteBuilder ? Well, it's just a factorization of the code that is
commonly used to construct a suite. But it also adds a functionnality:
TestCase name extraction using RTTI (note, that it was originaly located in
the TestSuite constructor, which make more sense to me).
  TestSetUp allow you to set up an environment to run a test.
  RepeatedTest allow  you to run a test a specified number of times.
  For those last two, their only purpose is to provide new functionnalities.

  So the edge is somewhat blurred. The hardest to define probably being the
TestFactoryRegistry.

  Ahh, I think I found a good criteria: "If you did not have this class,
could you do what it is doing without rewriting it ? If so, then it is not
an extension".

  I hope this help, it sure sharpened some blurred shapes for me. I like
that last criteria.

  Baptiste.
---
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).

Re: [Cppunit-devel] include directory clean-up

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

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

> On Thu, Jun 14, 2001 at 04:39:41PM +0200, Baptiste Lepilleur wrote:
> 
> > We had some talk about the namespace a while ago, and questions
> > about why so many stuffs were in the "extensions" directory. I think
> > the current directory orgnization in "include" can be confusing.
> 
> I agree with this sentiment.  It confuses me :-)
> 
> Unfortunately, I have more questions than answers...
> 
> I think that drafting an outline of the library will help in
> organizing the directory structure (and possibly the namespace
> structure).  Questions that I have, for example: what is the
> difference between an "extension" and a "helper"?  What is the "core"
> of the framework, anyway?

  I'll try to define those as I perceive them:

core: it is the minimal(not really) set of classes for unit testing. It 
provides the following functionnalities:
 - writing (TestAssert) and running test (Test). 
 - report test failure 
(TestCase,TestResult,Exception,NotEqualException,TestListener)
 - organize test in suite (TestSuite)
 I would also include:
 - being able to write a test in a single class method (TestCaller)
 - should be extensible

extensions: they extends the functionnalities provided by the framework.
helper(s?): they don't add functionnalities but make using existing 
functionnalities easier.


Well, I'll have to go back home. I'll extend a bit later on this that evening.

Later,
Baptiste.


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

Re: [Cppunit-devel] include directory clean-up

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

On Thu, Jun 14, 2001 at 04:39:41PM +0200, Baptiste Lepilleur wrote:

> We had some talk about the namespace a while ago, and questions
> about why so many stuffs were in the "extensions" directory. I think
> the current directory orgnization in "include" can be confusing.

I agree with this sentiment.  It confuses me :-)

Unfortunately, I have more questions than answers...

I think that drafting an outline of the library will help in
organizing the directory structure (and possibly the namespace
structure).  Questions that I have, for example: what is the
difference between an "extension" and a "helper"?  What is the "core"
of the framework, anyway?

I'd like to start documenting the classes better.  I don't understand
it well enough, yet, though.  If we can get some discussion going
here, I will add the documentation strings.  I expect this process
will clarify class relationships and groupings will emerge,
facilitating directory/namespace structuring.

For example, we can start with the core classes such as Test,
TestCase, TestCaller, TestSuite.  The latter three are each a subclass
of Test, which is pure virtual.  Is it fair to say, then, that
Test is an "interface" class?  What are the intended semantics
of its methods: run(), countTestCases(), toString() and getName()?
We just had some questions on whether the latter two should be
merged.  I don't think a conclusion was reached.


>   textui/: text based TestRunner
>     TestRunner.h  (within the CppUnit::TextUi namespace, was TextTestRunner.h)
>   mfcui/: MFC based TestRunner
>     TestRunner.h  (within the CppUnit::MfcUi namsepace, was 
> msvc6/TestRunner/TestRunner.h )

Here, the directory structure is intended to mirror the namespace
structure, right?  I wonder what is intended to be in the
CppUnit::<UI> namespace.  Currently, there is only TestRunner; are
more classes envisioned?  If not, we'd be creating multiple <UI>
namespaces with a single member each.  That doesn't sound right.  Why
not create a TestRunner base class, with specializations for each UI?


-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

[Cppunit-devel] include directory clean-up

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

We had some talk about the namespace a while ago, and questions about why so 
many stuffs were in the "extensions" directory. I think the current directory 
orgnization in "include" can be confusing.

Here I propose a new organization below the "include" directory:

cppunit/
  extensions/ : only stuffs that really "extends" the framework
    Orthodox.h
    RepeatedTest.h
    TestDecorator.h
    TestSetUp.h
  helper/: stuffs that make using the framework easier
    AutoRegisterSuite.h
    HelperMacros.h
    TestFactory.h
    TestFactoryRegistry.h
    TestSuiteBuilder.h
    TestSuiteFactory.h
    TypeInfoHelper.h
  textui/: text based TestRunner
    TestRunner.h  (within the CppUnit::TextUi namespace, was TextTestRunner.h)
  mfcui/: MFC based TestRunner
    TestRunner.h  (within the CppUnit::MfcUi namsepace, was 
msvc6/TestRunner/TestRunner.h )

So, what do you think ?

Baptiste.

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

[Cppunit-devel] Re: TestFactoryRegistry and Library

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

Quoting Baptiste Lepilleur <gai...@fr...>:

This is a follow up to Michael Gerleck second question in the forum.
 
> Quoting Michael Gerleck:
> Well, it turns out I can't make use of the registry functionality
> anyway: near 
> as I can tell, global ctor's in libraries aren't exported to the calling
> 
> context under MSVC6. That is, 
> 
> - suite1.lib contains a bunch of testscases, all auotregister'd into
> "Suite1" 
> 
> - main driver contains the line 
> masterSuite->addTest( CppUnit::TestFactoryRegistry::getRegistry
> ("Suite1").makeTest() ); 
> 
> At runtime, the registry lookup doesn't find "Suite1", because the ctor
> wasn't 
> linked in to the executable -- because there's no reference to it from
> main. 
  I'm don't what is the "Global constructor" you are refering to. The registry 
use a static variable:

TestFactoryRegistry &
TestFactoryRegistry::getRegistry()
{
  static TestFactoryRegistry registry;   <<<
  return registry;
}

To my knowlegde, the behavior you are observing is the normal behavior.

Anyway, there are some simple workaround. Have your librairies publishing an 
interface that provide an access to their TestFactoryRegistry.

For example, in suite1.lib project, you add:

TestFactoryRegistry &getSuite1Registry() {
  return TestFactoryRegistry::getRegistry();
}

Since this function is compiled within suite1.lib, it returns a reference to 
the registry used within suite1.lib.

In the main driver you can then do:
masterSuite->addTest( getSuite1Registry().getRegistry
("Suite1").makeTest() ); 

This should work (I haven't tried). An alternative that I find much cleaner 
would be to either publish the TestSuite, or provide an indirect access to the 
registry:

class SuiteProvider
{
   TestSuite *suite()
   {
     // Here you can play anyway you want with the registry, or create the
     // suite by hand if you don't want to use the registry.
     return TestFactoryRegistry::getRegistry().makeTest();
     // or
     return new AllTestSuite();
   } 
   // or
   TestSuite *suiteFor( std::string name )
   {
     return TestFactoryRegistry::getRegistry( name ).makeTest(); 
   }

};

Well, as you see much can be done.


> 
> [Editorial: I suspect MSVC6 is broken here, because it only fails to
> work when 
> Suite1 is in a separate library. Global ctors should always be
> respected, no?] 
> 
> This is a pain, because I've got a lot of testcases and a lot of
> libraries and 
> a lot of developers to deal with -- it would have been nice to have it
> all just 
> magically work, without a lot of explicit includes and suite creation
> calls. So 
> much for the magic of registries and factories; back to the drawing
> board... 
  I'd really like to know how the TestRunner react with so many suite... How 
many TestCase did you end up with ?

> 
> I'll migrate over to the dev-list. 
> 
> -mpg 

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

[Cppunit-devel] TestRegistryFactory and named suite registration...

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

This is a follow up to Michael Gerlek question in the forum: "Possible bugs in 
Registry extension files?"

The TestFactoryRegistry allow you to register a suite with a given name, and 
the AutoRegisterSuite named constructor allow you to automatically to that.

This work well. The problem come when you try to register a named suite created 
into the TestFactoryRegistry into another TestFactoryRegistry.

For example, if you want to have the following suite hierarchy:

All Tests
  Functionnal
    Model
    Message  
  UnitTest

You should be able to do:
TestFactoryRegistry &allTests = TestFactoryRegistry::getRegistry()
TestFactoryRegistry &functionnal = TestFactoryRegistry::getRegistry
( "Functionnal" )
allTests.registerFactory( functionnal )

This would add the "Functionnal" suite a child of "All Tests"

functionnal.registerFactory( TestFactoryRegistry::getRegistry("Model" ) );
functionnal.registerFactory( TestFactoryRegistry::getRegistry("Message" ) );

This make the "Model" and "Message" suites children of the "Functionnal" suite.

This nifty tricks allow you to retreive a full suite hierarchy with: 
allTests.makeTest() ;-)

The problem is that the registry assumes ownership of registered test. As a 
result, suite registered this way would be destroyed twice. I still haven't 
though much about a way to solve the problem. Ideas are welcome.

Once this problem is solved, we can go ahead and add a 
CPPUNIT_TEST_SUITE_NAMED_REGISTRATION as suggested by Michael.

Baptiste.

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

[Cppunit-devel] TestRegistryFactory and named suite registration...

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

This is a follow up to Michael Gerlek question in the forum: "Possible bugs in 
Registry extension files?"

The TestFactoryRegistry allow you to register a suite with a given name, and 
the AutoRegisterSuite named constructor allow you to automatically to that.

This work well. The problem come when you try to register a named suite created 
into the TestFactoryRegistry into another TestFactoryRegistry.

For example, if you want to have the following suite hierarchy:

All Tests
  Functionnal
    Model
    Message  
  UnitTest

You should be able to do:
TestFactoryRegistry &allTests = TestFactoryRegistry::getRegistry()
TestFactoryRegistry &functionnal = TestFactoryRegistry::getRegistry
( "Functionnal" )
allTests.registerFactory( functionnal )

This would add the "Functionnal" suite a child of "All Tests"

functionnal.registerFactory( TestFactoryRegistry::getRegistry("Model" ) );
functionnal.registerFactory( TestFactoryRegistry::getRegistry("Message" ) );

This make the "Model" and "Message" suites children of the "Functionnal" suite.

This nifty tricks allow you to retreive a full suite hierarchy with: 
allTests.makeTest() ;-)

The problem is that the registry assumes ownership of registered test. As a 
result, suite registered this way would be destroyed twice. I still haven't 
though much about a way to solve the problem. Ideas are welcome.

Once this problem is solved, we can go ahead and add a 
CPPUNIT_TEST_SUITE_NAMED_REGISTRATION as suggested by Michael.

Baptiste.

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

RE: [Cppunit-devel] STL concepts checking (was: Change done...)

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

Quoting Bastiaan Bakker <bas...@li...>:
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: Baptiste Lepilleur [mailto:bl...@cl...]
> > Verzonden: Tuesday, June 12, 2001 9:20 AM
> > Aan: cpp...@li...
> > Onderwerp: Re: [Cppunit-devel] Change done...

> >     Is there a place where those STL concepts can be look up 
> > (my knowledge
> > is empirical)?
> 
> The June 2001 issue of Dr. Dobbs contains an article on C++ concept
> checking. They refer to the Boost Concept Checking Library:
> http://www.boost.org/libs/concept_check/concept_check.htm. Seems
> interesting.
  Thanks. I knew about the boost library concept checking but never got farther 
than the introduction. I took the time to read a bit more and came to the 
following conclusion: 

  Concept check can be added transparently to existing code.

  Can someone with some experience with the boost library confirm that ?

  For us, it would mean that we could go ahead and implements the unit test for 
those concepts, and later add compile time concept checking (some option to use 
boost?).

  First concept I'd like to add would be Assignable and CopyConstructible (I'm 
refering to boost concept which are more fine grained: 
http://www.boost.org/libs/concept_check/reference.htm ).

  Those are used for example in the unit tests for Exception and 
NotEqualException (they did reaveal some bugs...).

  The difficulty for us is that you need to specify how you compare two 
instances (for example, with Exception, I compare the result of what() for each 
instance). You also need to specify one or more instance that are used for the 
tests. I'm not sure of how do to that.

I was thinking of using functors or something like that. Any ideas ? I would 
like the final form to be able to mesh well with existing macros, so you could 
simply add a few macro to check the concepts.


> Of course the descriptions of the STL concepts themselves can be found
> at
> SGI's STL pages: http://www.sgi.com/tech/stl/
   Thanks, this doc is really good.

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

Re: [Cppunit-devel] Change done...

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

----- Original Message ----- 
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Tuesday, June 12, 2001 12:09 AM
Subject: Re: [Cppunit-devel] Change done...


> I couldn't get examples/cppunit/OrthodoxTest.cpp to compile, and
> I couldn't figure out how to fix it.  Specifically, I don't understand
> what is intended by all the "operator !()" functions.  They are
> declared to return an object of class "Value", but in each case
> the return statement is computing an integer.
    I added explicit construction to operator !. It might help.

    Baptiste.
---
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).

RE: [Cppunit-devel] Change done...

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Baptiste Lepilleur [mailto:bl...@cl...]
> Verzonden: Tuesday, June 12, 2001 9:20 AM
> Aan: cpp...@li...
> Onderwerp: Re: [Cppunit-devel] Change done...
> 

--8<--

>     Is there a place where those STL concepts can be look up 
> (my knowledge
> is empirical)?
> 

The June 2001 issue of Dr. Dobbs contains an article on C++ concept
checking. They refer to the Boost Concept Checking Library:
http://www.boost.org/libs/concept_check/concept_check.htm. Seems
interesting.
Of course the descriptions of the STL concepts themselves can be found at
SGI's STL pages: http://www.sgi.com/tech/stl/

Good luck,

Bastiaan

>     Baptiste.
> 
> ---
> 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 mailing list
Cpp...@li...
http://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] Change done...

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Tuesday, June 12, 2001 12:09 AM
Subject: Re: [Cppunit-devel] Change done...


> On Mon, Jun 11, 2001 at 10:25:46PM +0200, Baptiste Lepilleur wrote:
> > Well, I finally comitted the thing. I checkout the project and it
compiled
> > fine, so everything should be there (a lot of files have been added).
>
> After some fine-tuning, I got it compiled under unix, with one
> exception.
>
>
> > You should have exactly 80 unit tests running in cppunittests,
>
> I couldn't get examples/cppunit/OrthodoxTest.cpp to compile, and
> I couldn't figure out how to fix it.  Specifically, I don't understand
> what is intended by all the "operator !()" functions.  They are
> declared to return an object of class "Value", but in each case
> the return statement is computing an integer.
>
> After omitting OrthodoxTest, I got 72 tests which all passed.
    There is one missing. You should have 73 tests.

With this morning update (NotEqualException/assertEquals), you should have
(with OrthodoxTest disabled):

Run:  77   Failures: 1   Errors: 0
There was 1 failure:
1) test: ExceptionTest.testAssignment line: 103
g:\prg\vc\lib\cppunit\examples\c
ppunittest\exceptiontest.cpp
expected: message
but was:  Unknown exception

>
>
> -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
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

Re: [Cppunit-devel] Change done...

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

----- Original Message -----
From: "Townsend, Guy" <gto...@sh...>
To: <cpp...@li...>
Sent: Tuesday, June 12, 2001 12:50 AM
Subject: RE: [Cppunit-devel] Change done...


> That "operator !()" in OrthodoxTest test has always bothered me. It's okay
> for a very few classes, but just doesn't apply for most of the classes I
> write. Which makes  OrthodoxTest not very useful. Parts of it are good,
but
> the negation of most classes doesn't seem to make sense. Perhaps that part
> should be at least #ifdef'd out unless one really wants to use it for an
> appropriate class?
>
> Guy

#ifdef would be bad, because depending of the project you would be reading,
the semantic would change.

>
>
> > -----Original Message-----
> > From: Steve M. Robbins [mailto:ste...@vi...]
> > Sent: Monday, June 11, 2001 3:09 PM
> > To: cpp...@li...
> > Subject: Re: [Cppunit-devel] Change done...
> >
> >
> > On Mon, Jun 11, 2001 at 10:25:46PM +0200, Baptiste Lepilleur wrote:
> > > Well, I finally comitted the thing. I checkout the project
> > and it compiled
> > > fine, so everything should be there (a lot of files have
> > been added).
> >
> > After some fine-tuning, I got it compiled under unix, with one
> > exception.
> >
> >
> > > You should have exactly 80 unit tests running in cppunittests,
> >
> > I couldn't get examples/cppunit/OrthodoxTest.cpp to compile, and
> > I couldn't figure out how to fix it.  Specifically, I don't understand
> > what is intended by all the "operator !()" functions.  They are
> > declared to return an object of class "Value", but in each case
> > the return statement is computing an integer.
> >
> > After omitting OrthodoxTest, I got 72 tests which all passed.
> >
> >
> > -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
> >
> >
> > _______________________________________________
> > Cppunit-devel mailing list
> > Cpp...@li...
> > http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> >
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

Re: [Cppunit-devel] Change done...

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Tuesday, June 12, 2001 2:29 AM
Subject: Re: [Cppunit-devel] Change done...


> On Mon, Jun 11, 2001 at 03:50:26PM -0700, Townsend, Guy wrote:
> > That "operator !()" in OrthodoxTest test has always bothered me. It's
okay
> > for a very few classes, but just doesn't apply for most of the classes I
> > write. Which makes  OrthodoxTest not very useful. Parts of it are good,
but
> > the negation of most classes doesn't seem to make sense. Perhaps that
part
> > should be at least #ifdef'd out unless one really wants to use it for an
> > appropriate class?
>
> Another random thought: rather than "orthodox", perhaps it makes more
> sense to template unit tests for STL concepts like Assignable,
> EqualityComparable, DefaultConstructible, and whatnot.

    Yes that would make a lot of sense (look at the TODO file ;-) ).

    The current Orthodox test is not very usable because you need to look up
the code to know which assertion failed. It would be better if we had more
fine grained test which name would make sense. We could then compose those
test for common "concept".

    Is there a place where those STL concepts can be look up (my knowledge
is empirical)?

    Baptiste.

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

Re: [Cppunit-devel] Change done...

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

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Tuesday, June 12, 2001 12:09 AM
Subject: Re: [Cppunit-devel] Change done...


> On Mon, Jun 11, 2001 at 10:25:46PM +0200, Baptiste Lepilleur wrote:
> > Well, I finally comitted the thing. I checkout the project and it
compiled
> > fine, so everything should be there (a lot of files have been added).
>
> After some fine-tuning, I got it compiled under unix, with one
> exception.
>
>
> > You should have exactly 80 unit tests running in cppunittests,
>
> I couldn't get examples/cppunit/OrthodoxTest.cpp to compile, and
> I couldn't figure out how to fix it.  Specifically, I don't understand
> what is intended by all the "operator !()" functions.  They are
> declared to return an object of class "Value", but in each case
> the return statement is computing an integer.
    It use the implicit constructor of Value which take an integer.

    I had an hard time thinking for a ! operator, and that probably reflect.

>
> After omitting OrthodoxTest, I got 72 tests which all passed.
>
>
> -S
---
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).

Re: [Cppunit-devel] Change done...

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

On Mon, Jun 11, 2001 at 03:50:26PM -0700, Townsend, Guy wrote:
> That "operator !()" in OrthodoxTest test has always bothered me. It's okay
> for a very few classes, but just doesn't apply for most of the classes I
> write. Which makes  OrthodoxTest not very useful. Parts of it are good, but
> the negation of most classes doesn't seem to make sense. Perhaps that part
> should be at least #ifdef'd out unless one really wants to use it for an
> appropriate class?

Another random thought: rather than "orthodox", perhaps it makes more
sense to template unit tests for STL concepts like Assignable,
EqualityComparable, DefaultConstructible, and whatnot.  

-- 
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] Change done...

[Townsend, G. <gto...@sh...>]

That "operator !()" in OrthodoxTest test has always bothered me. It's okay
for a very few classes, but just doesn't apply for most of the classes I
write. Which makes  OrthodoxTest not very useful. Parts of it are good, but
the negation of most classes doesn't seem to make sense. Perhaps that part
should be at least #ifdef'd out unless one really wants to use it for an
appropriate class?

Guy


> -----Original Message-----
> From: Steve M. Robbins [mailto:ste...@vi...]
> Sent: Monday, June 11, 2001 3:09 PM
> To: cpp...@li...
> Subject: Re: [Cppunit-devel] Change done...
> 
> 
> On Mon, Jun 11, 2001 at 10:25:46PM +0200, Baptiste Lepilleur wrote:
> > Well, I finally comitted the thing. I checkout the project 
> and it compiled
> > fine, so everything should be there (a lot of files have 
> been added).
> 
> After some fine-tuning, I got it compiled under unix, with one
> exception.
> 
> 
> > You should have exactly 80 unit tests running in cppunittests, 
> 
> I couldn't get examples/cppunit/OrthodoxTest.cpp to compile, and
> I couldn't figure out how to fix it.  Specifically, I don't understand
> what is intended by all the "operator !()" functions.  They are
> declared to return an object of class "Value", but in each case
> the return statement is computing an integer.
> 
> After omitting OrthodoxTest, I got 72 tests which all passed.
> 
> 
> -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
> 
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

Re: [Cppunit-devel] toString() is not used...

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

On Sat, Jun 10, 2000 at 02:59:02PM +0200, Baptiste Lepilleur wrote:
>     Well, I looked around in the code, and the method toString() which is
> defined in most of the classes does not seem to be used (getName() is used
> instead).
> 
>     Since it is not used, why  not remove it ? I think this is a leftover
> from the junit port, but I don't see any use for it.
> 
>     Having a toString() and a getName() is confusing for newbies (I remember
> I was confused at first).

I think it is confusing mainly because the base class Test doesn't
document what the two functions are supposed to do.  [Indeed, Test
doesn't document what *any* of its functions are supposed to do.]

I'm all for simplifying the interface.  I guess we'll have to first
articulate what these functions are intended to do.  TestCase (a
subclass of Test), for example, defines toString() and getName()
differently.  TestCase objects have a "name" (m_name, rather)
variable; getName() returns this name.  The function toString(),
however, prepends a class name to it.

The behaviour of toString() seems quite useful; maybe that is the
interface to standardize on.  I haven't really looked at the code
closely.  Hopefully someone with a longer history with the project
will speak up ;-)

-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] Change done...

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

On Mon, Jun 11, 2001 at 10:25:46PM +0200, Baptiste Lepilleur wrote:
> Well, I finally comitted the thing. I checkout the project and it compiled
> fine, so everything should be there (a lot of files have been added).

After some fine-tuning, I got it compiled under unix, with one
exception.


> You should have exactly 80 unit tests running in cppunittests, 

I couldn't get examples/cppunit/OrthodoxTest.cpp to compile, and
I couldn't figure out how to fix it.  Specifically, I don't understand
what is intended by all the "operator !()" functions.  They are
declared to return an object of class "Value", but in each case
the return statement is computing an integer.

After omitting OrthodoxTest, I got 72 tests which all passed.


-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

[Cppunit-devel] Change done...

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

Well, I finally comitted the thing. I checkout the project and it compiled
fine, so everything should be there (a lot of files have been added).

You should have exactly 80 unit tests running in cppunittests, and one
failing among those (that means 79 passing). If you don't, I somehow messed
up while updating the make file (and I probably forgot to update the
ChangeLog for that test too).

I'd like if someone could check the failing test case. It's
ExceptionTest::testAssignment(). I tried to find what's wrong, but I just
don't get it.

Here is what we should try to do the next time we make some change to
CppUnit:
- look over the unit test for the class
- if you have an hard time figuring out what a test did, rename it! (and
make sure to make it fail to see if it is still run)
- add a test for the new feature or to demonstrate the bug that is being
fixed

This should let us have a got test suite over time... To bad this can't be
applied for portability fix :-(.

Note that the code could use some refactoring. Many test that run TestCase
have an m_result instance and a checkResult() method...

There is a remaing unit test for NotEqualException to write, and use that
exception with the assertEquals().

Have fun,
Baptiste.
---
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).