cppunit-devel — CppUnit Developer Mailing List

Re: [Cppunit-devel] Parameterizing tests by using XML

[Robert W. <ro...@po...>]

Hi,

On Friday 19 July 2002 08:36, Michel Armin wrote:
> Hi all.
>
> Actually I was thinking about a little bit different solution here.
> It differs mainly in two points:
>
> 1. the framework should be responsible for parsing the xml file and
> invoke the test with a particular set of parameters (as opposed to
> let each of the test cases perform the parsing)
>
> 2. the DTD of the xml file is a less sophisticated

These are _very_ important points -- you would not want to need test 
cases for your test cases, right?

I still see two big drawbacks on using a XML driven test.

First it drops the advantage of having the tests written in the same 
language as the code under test. Developers have to learn another new 
language / syntax / semantics and can not focus on their real work. 
Even though XML looks easy, it has some pitfalls you will most likely 
uncover and which will cost really lots of time, nerves, and sanity.

Second I don't think the XML overhead justifies the results. How many 
tests do you have that run the same way that you just need to exchange 
the input and output values? (And how many of those use primitive 
inputs and outputs?) If I ever have to write more than three tests for 
the same method, I think hard about abetter design, usually the method 
has just too much responsibilities.

Just my 2 cents,

Robert

RE: [Cppunit-devel] Parameterizing tests by using XML

[Michel A. <Arm...@si...>]

Hi all.

Actually I was thinking about a little bit different solution here. It
differs mainly in two points:

1. the framework should be responsible for parsing the xml file and invoke
the test with a particular set of parameters (as opposed to let each of the
test cases perform the parsing)

2. the DTD of the xml file is a less sophisticated

It follows a short description of my suggestion:

A (new) BEGIN_TEST_SUITE macro is able to accept the name of a (input-)
file. If this (new) macro is used a new type of TestCaller
(ParameterizedTestCaller) will be used for this suite. If a
ParameterizedTestCaller  is executing its test, it will scan the in-file for
a section for this particular test. The section will be parsed and a
TestSuite object will be created that contains one Test object for each set
of parameters. This newly created TestSuite object will then be executed
using the run(TestResult* result) method.
The (parameterized) test method will be called with two std::istreams: the
one contains the (input) parameters, the other one contains  expected
results (can also be an empty stream). Thus the test method is able to read
its parameters using the operator>>. If there is no section for a test
method, it is only called once (with no parameters?).

Example:

MyTest.xml:

<test name=”testMethod”>
    <call name=”simple”>
        <description>
            Simple and valid set of parameters.
            Format of “in” is: “int int std::string”
            Format of “exp” is: “int”
        </description>
        <in>
            3 -1 myCorrectString
        </in>
        <exp>
            25
        </exp>
    </call>
</test>

MyTest.cpp:

void testMethod(std::istream& param_in, std::istream& exp_in)
{
    int param1, param2;
    std::string param3;

    param_in >> param1 >> param2 >> param3;

    int exp;
    
    exp_in >> exp;

    // perform tests using these parameters ...
}

I was also thinking about introducing a TestContext class that would be
responsible for hosting the information gained from the xml file (e.g. input
and expected streams). But I am not sure about how to do this in a way that
a improved flexibility/exchangability is gained. I will expand this issue in
a separate email...

Regards

Armin


> -----Original Message-----
> From: FUKUDA Fumiki [mailto:ff...@nt...]
> Sent: Freitag, 19. Juli 2002 01:25
> To: cpp...@li...
> Subject: Re: [Cppunit-devel] Parameterizing tests by using XML
> 
> 
> Hi.
> 
> --- "[Cppunit-devel] Parameterizing tests by using XML" / 
> Steffen Huebner / 2002/07/18 16:07:43 +0200 ---
> >I have looked over CppUnit the last time to find a way 
> making tests more 
> >flexible by parameterizing them.
> >The idea is to place input parameters and corresponding 
> expected values in a XML file. 
> >That forces to parse the incoming XML file.
> >...
> 
> I'm now trying this. 
> 
> - format of testdata(XML) is identical to JTestCase 
> (http://jtestcase.sourceforge.net/)
> 
> <tests>
>   <class name="CalculatorTest">
>     <!-- Sample global params --> 
>     <params>
>       <param name="gVar1" type="double">10</param>
>       <param name="gVar2" type="int">30</param>
>     </params>
>     <!-- params & asserts for CalculatorTest::testCalculate() -->
>     <method name="testCalculate" test-case="positive-add">
>       <!-- expected: 10 + 20 = 30 -->
>       <params>
>         <param name="var1" type="int">10</param>
>         <param name="var2" type="int">20</param>
>         <param name="opt">+</param>
>       </params>
>       <asserts>
>         <assert name="result" type="int" action="EQUALS">30</assert>
>       </asserts>
>     </method>
>     <!--- and so on -->
>   </class>
> </tests>
> 
> ... and I made class: TextContext/TestContextProxy.
> you can use as follows:
> 
> class CalculatorTest : public CppUnit::TestFixture {
>   CPPUNIT_TEST_SUITE(CalculatorTest);
>   CPPUNIT_TEST(testCalculate);
>   CPPUNIT_TEST_SUITE_END();
> private:
> 
>   TestContext* tc_;
> 
>   static int atoi(const std::string& str) {
>     int result;
>     std::istringstream strm(str);
>     strm >> result;
>     return result;
>   }
> 
> public:
> 
>   virtual void setUp() {
>     // load an XML & set the name of class
>     tc_ = new XercesTestContext("../data/testcase.xml", 
> "CalculatorTest");
>   }
>   virtual void tearDown()
>     { delete tc_; }
> 
>   void testCalculate() {
>     // make a proxy from TestContext & name of method
>     TestContextProxy proxy(tc_,"testCalculate");
>     // enumerate params/asserts 
>     while ( proxy.advance() ) {
>       // extract params
>       TestContext::params_type params = proxy.getTestCaseParams();
>       int x = atoi(params["var1"]);
>       int y = atoi(params["var2"]);
>       char op = params["opt"][0];
>       // execute
>       Calculator c;
>       int result = c.calculate(x,y,op);
>       // verify!
>       CPPUNIT_ASSERT_CONTEXTPROXY(proxy, "result", result);
>     }
>   }
> };
> 
> sounds good? ;-)
> 
> -----:-----:-----:-----:-----:-----:-----:-----:-----:-----
> FUKUDA (episteme) Fumiki -- magical, but never a magic...
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

Re: [Cppunit-devel] Parameterizing tests by using XML

[FUKUDA F. <ff...@nt...>]

Hi.

--- "[Cppunit-devel] Parameterizing tests by using XML" / Steffen Huebner / 2002/07/18 16:07:43 +0200 ---
>I have looked over CppUnit the last time to find a way making tests more 
>flexible by parameterizing them.
>The idea is to place input parameters and corresponding expected values in a XML file. 
>That forces to parse the incoming XML file.
>...

I'm now trying this. 

- format of testdata(XML) is identical to JTestCase (http://jtestcase.sourceforge.net/)

<tests>
  <class name="CalculatorTest">
    <!-- Sample global params --> 
    <params>
      <param name="gVar1" type="double">10</param>
      <param name="gVar2" type="int">30</param>
    </params>
    <!-- params & asserts for CalculatorTest::testCalculate() -->
    <method name="testCalculate" test-case="positive-add">
      <!-- expected: 10 + 20 = 30 -->
      <params>
        <param name="var1" type="int">10</param>
        <param name="var2" type="int">20</param>
        <param name="opt">+</param>
      </params>
      <asserts>
        <assert name="result" type="int" action="EQUALS">30</assert>
      </asserts>
    </method>
    <!--- and so on -->
  </class>
</tests>

... and I made class: TextContext/TestContextProxy.
you can use as follows:

class CalculatorTest : public CppUnit::TestFixture {
  CPPUNIT_TEST_SUITE(CalculatorTest);
  CPPUNIT_TEST(testCalculate);
  CPPUNIT_TEST_SUITE_END();
private:

  TestContext* tc_;

  static int atoi(const std::string& str) {
    int result;
    std::istringstream strm(str);
    strm >> result;
    return result;
  }

public:

  virtual void setUp() {
    // load an XML & set the name of class
    tc_ = new XercesTestContext("../data/testcase.xml", "CalculatorTest");
  }
  virtual void tearDown()
    { delete tc_; }

  void testCalculate() {
    // make a proxy from TestContext & name of method
    TestContextProxy proxy(tc_,"testCalculate");
    // enumerate params/asserts 
    while ( proxy.advance() ) {
      // extract params
      TestContext::params_type params = proxy.getTestCaseParams();
      int x = atoi(params["var1"]);
      int y = atoi(params["var2"]);
      char op = params["opt"][0];
      // execute
      Calculator c;
      int result = c.calculate(x,y,op);
      // verify!
      CPPUNIT_ASSERT_CONTEXTPROXY(proxy, "result", result);
    }
  }
};

sounds good? ;-)

-----:-----:-----:-----:-----:-----:-----:-----:-----:-----
FUKUDA (episteme) Fumiki -- magical, but never a magic...

RE: [Cppunit-devel] standard way to handle test data

[Moran Ben-D. <mbe...@ii...>]

Thanks for examining my points.. I think I'm a bit confused by the term
TestResult.. Due to it's name, I was under the impression that it is the
output of the test.. where as TestContext (due to it's name) would be the
input.. perhaps I misread one or the other.. I'll reread and examine the way
TestResult is passed to the test method.. 
 
thanks again.
moran

-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: Wednesday, July 17, 2002 3:52 PM
To: Moran Ben-David; cpp...@li...
Subject: Re: [Cppunit-devel] standard way to handle test data


I gave a quick look at this. TestDriver is our TestRunner and TestContext is
our TestResult. Though, the main difference is that the TestResult is passed
to the test method. I don't believe this to be really necessary. I could
understand passing it to setUp() and tearDown() but to pass to the test
method reduce the decoupling of the test with the outside world (at least to
me).
 
On another note, I also gave a quick look over JTestCase. I once implemented
some functional tests based on some Excel sheet. Though, instead of reading
the data in a test case, I read the data in a subclassed test suite which
populated itself by creating a test case for each set of data. Though,
JTestCase seems to go a bit farther than this...
 
Baptiste.

----- Original Message ----- 
From: Moran  <mailto:mbe...@ii...> Ben-David 
To: 'Baptiste Lepilleur' <mailto:gai...@fr...>  ;
cpp...@li...
<mailto:cpp...@li...>  
Sent: Wednesday, July 10, 2002 9:03 PM
Subject: RE: [Cppunit-devel] standard way to handle test data

TestContext to me would be a class that would be passed to Tests each time
they are run.  The Test receiving the context would use it to extract data
necessary for it's test.
 
In my search for separating the data (e.g. primary keys of rows being pulled
from the database, etc.) from my Test Fixture code.. I came accross this:
 
http://c2.com/cgi/wiki?TestDriver <http://c2.com/cgi/wiki?TestDriver> 
 
This page mentions the TestContext class for encapsulating the data required
by a test.. I'm not 100% clear on how I'd like to data-drive my TestFixtures
however, I know I need to as currently I'm hardcoding the, for example,
database primary keys I'm trying to pull from the db to test my querying
code.
 
Forgive my ignorance.. but are you on the cppunit development team?
Moran

-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: Wednesday, July 10, 2002 1:32 PM
To: Moran Ben-David; cpp...@li...
Subject: Re: [Cppunit-devel] standard way to handle test data


Could you explain shortly what is that TextContext class ? 
 
Recently, I was thinking about passing the TestResult to the setUp() and
tearDown() methods. I can be done without too much trouble, but I still
haven't come up with some really good reason (might change though).
 
Baptiste.

----- Original Message ----- 
From: Moran  <mailto:mbe...@ii...> Ben-David 
To: 'cpp...@li...'
<mailto:'cpp...@li...'>  
Sent: Sunday, July 07, 2002 4:07 AM
Subject: [Cppunit-devel] standard way to handle test data


Hi. 

I'm looking for a standard way for making my TestFixtures data driven.  I've
read some suggestions about a TextContext class and seen JTestCase (
http://jtestcase.sourceforge.net/ <http://jtestcase.sourceforge.net/> )..
Rather than write my own implemention of one or more of these concepts for
CppUnit, I'd rather use a popular implemention.  Is there one?

Thanks, 
Moran 

---------------------|||| ii3 | 
Moran Ben-David 
ii3 Inc. 
t)  416.595.5232 x294 
f)  416.595.5224 
e)  mbe...@ii... 
i)   < http://www.ii3.com/ <http://www.ii3.com/> > 

--------------- eBusiness.  Your Vision Here. 

RE: [Cppunit-devel] Parameterizing tests by using XML

[Moran Ben-D. <mbe...@ii...>]

To follow your raising of the overhead issue.. 

Although XML is great, it is a bit beurocratic when all you want to send
your test case is a an integer.. I think the best approach to data driving
the test cases is to start with stl containers (e.g. map).. e.g. a test case
receives a list of keys and values created when the test is setup in the
runner.

As for the design of this, I am not sure.. however, as long as the person(s)
writing and feeding the tests are able to decide data structure that is
passed (e.g. stl container, xml dom, etc.), the framework will be best.

thanks,
moran

-----Original Message-----
From: Duane Murphy [mailto:dua...@ma...]
Sent: Thursday, July 18, 2002 12:10 PM
To: CppUnit Developers
Subject: Re: [Cppunit-devel] Parameterizing tests by using XML


I think moving to or adding a data driven interface to cppUnit would be a
great feature. I have considered it myself.

XML is certainly the right way of doing this. It allows tests to be
written by hand or generated by some automated tool. This certainly
doesnt absolve the developer from writing test code, but a good design
should make it easier to focus on the test rather than the test
environment. One of my personal deterants to cppunit has been the
overhead involved in getting test registered in order to run. A data
driven approach would be great.

[ more comments below ]

--- At Thu, 18 Jul 2002 16:07:43 +0200, Steffen Huebner wrote:

>I have looked over CppUnit the last time to find a way making tests more
>flexible by parameterizing them.
>The idea is to place input parameters and corresponding expected values
>in a XML file. 
>That forces to parse the incoming XML file.
>Having a common interface that gives the possibility to parse the XML
>file is our way to do so.
>At the moment I don`t really know how this interface should look and
>which methods it should provide.
>
>My questions about this are:
>1. What do you think about an interface with the possibility to use
>different parsers?

The XML interface should not depend on any parser. Standard XML features
should work with most any parser. 

I suppose each parser does have its own interface. I was think more along
the lines of the XML file definition.

>2. Does such an interface for parsing already exists?
>
>I found MS XML and XML4C by Alphaworks(IBM) which are both useable in C++.

There is also libxml and libxml++. libxml++ is apparently still under
development. I wonder if an abstract interface can be developed that
would more easily allow different parsers to be used.

>3. Would that be a nice feature for your CppUnit-Framework?

Yes it would.

 ...Duane

-- 
"If tyranny and oppression come to this land, it will be in the
guise of fighting a foreign enemy."              - James Madison




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] standard way to handle test data

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

standard way to handle test dataI gave a quick look at this. TestDriver =
is our TestRunner and TestContext is our TestResult. Though, the main =
difference is that the TestResult is passed to the test method. I don't =
believe this to be really necessary. I could understand passing it to =
setUp() and tearDown() but to pass to the test method reduce the =
decoupling of the test with the outside world (at least to me).

On another note, I also gave a quick look over JTestCase. I once =
implemented some functional tests based on some Excel sheet. Though, =
instead of reading the data in a test case, I read the data in a =
subclassed test suite which populated itself by creating a test case for =
each set of data. Though, JTestCase seems to go a bit farther than =
this...

Baptiste.
  ----- Original Message -----=20
  From: Moran Ben-David=20
  To: 'Baptiste Lepilleur' ; cpp...@li...=20
  Sent: Wednesday, July 10, 2002 9:03 PM
  Subject: RE: [Cppunit-devel] standard way to handle test data


  TestContext to me would be a class that would be passed to Tests each =
time they are run.  The Test receiving the context would use it to =
extract data necessary for it's test.
  =20
  In my search for separating the data (e.g. primary keys of rows being =
pulled from the database, etc.) from my Test Fixture code.. I came =
accross this:
  =20
  http://c2.com/cgi/wiki?TestDriver
  =20
  This page mentions the TestContext class for encapsulating the data =
required by a test.. I'm not 100% clear on how I'd like to data-drive my =
TestFixtures however, I know I need to as currently I'm hardcoding the, =
for example, database primary keys I'm trying to pull from the db to =
test my querying code.
  =20
  Forgive my ignorance.. but are you on the cppunit development team?
  Moran
    -----Original Message-----
    From: Baptiste Lepilleur [mailto:gai...@fr...]
    Sent: Wednesday, July 10, 2002 1:32 PM
    To: Moran Ben-David; cpp...@li...
    Subject: Re: [Cppunit-devel] standard way to handle test data


    Could you explain shortly what is that TextContext class ?=20

    Recently, I was thinking about passing the TestResult to the setUp() =
and tearDown() methods. I can be done without too much trouble, but I =
still haven't come up with some really good reason (might change =
though).

    Baptiste.
      ----- Original Message -----=20
      From: Moran Ben-David=20
      To: 'cpp...@li...'=20
      Sent: Sunday, July 07, 2002 4:07 AM
      Subject: [Cppunit-devel] standard way to handle test data


      Hi.=20

      I'm looking for a standard way for making my TestFixtures data =
driven.  I've read some suggestions about a TextContext class and seen =
JTestCase (http://jtestcase.sourceforge.net/).. Rather than write my own =
implemention of one or more of these concepts for CppUnit, I'd rather =
use a popular implemention.  Is there one?

      Thanks,=20
      Moran=20

      ---------------------|||| ii3 |=20
      Moran Ben-David=20
      ii3 Inc.=20
      t)  416.595.5232 x294=20
      f)  416.595.5224=20
      e)  mbe...@ii...=20
      i)   <http://www.ii3.com/>=20

      --------------- eBusiness.  Your Vision Here.=20

Re: [Cppunit-devel] Parameterizing tests by using XML

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

I think moving to or adding a data driven interface to cppUnit would be a
great feature. I have considered it myself.

XML is certainly the right way of doing this. It allows tests to be
written by hand or generated by some automated tool. This certainly
doesnt absolve the developer from writing test code, but a good design
should make it easier to focus on the test rather than the test
environment. One of my personal deterants to cppunit has been the
overhead involved in getting test registered in order to run. A data
driven approach would be great.

[ more comments below ]

--- At Thu, 18 Jul 2002 16:07:43 +0200, Steffen Huebner wrote:

>I have looked over CppUnit the last time to find a way making tests more
>flexible by parameterizing them.
>The idea is to place input parameters and corresponding expected values
>in a XML file. 
>That forces to parse the incoming XML file.
>Having a common interface that gives the possibility to parse the XML
>file is our way to do so.
>At the moment I don`t really know how this interface should look and
>which methods it should provide.
>
>My questions about this are:
>1. What do you think about an interface with the possibility to use
>different parsers?

The XML interface should not depend on any parser. Standard XML features
should work with most any parser. 

I suppose each parser does have its own interface. I was think more along
the lines of the XML file definition.

>2. Does such an interface for parsing already exists?
>
>I found MS XML and XML4C by Alphaworks(IBM) which are both useable in C++.

There is also libxml and libxml++. libxml++ is apparently still under
development. I wonder if an abstract interface can be developed that
would more easily allow different parsers to be used.

>3. Would that be a nice feature for your CppUnit-Framework?

Yes it would.

 ...Duane

-- 
"If tyranny and oppression come to this land, it will be in the
guise of fighting a foreign enemy."              - James Madison

[Cppunit-devel] Parameterizing tests by using XML

[Steffen H. <ste...@we...>]

Hello,

I have looked over CppUnit the last time to find a way making tests more flexible by parameterizing them.
The idea is to place input parameters and corresponding expected values in a XML file. 
That forces to parse the incoming XML file.
Having a common interface that gives the possibility to parse the XML file is our way to do so.
At the moment I don`t really know how this interface should look and which methods it should provide.

My questions about this are:
1. What do you think about an interface with the possibility to use different parsers?

2. Does such an interface for parsing already exists?

I found MS XML and XML4C by Alphaworks(IBM) which are both useable in C++.

3. Would that be a nice feature for your CppUnit-Framework?

Regards

Steffen
______________________________________________________________________________
All inclusive! 100 MB Speicher, SMS 50% gunstiger, 32 MB Attachment-Gro?e, 
Preisvorteile und mehr unter http://club.web.de/?mc=021104

[Cppunit-devel] UnixWare problems...

[Tom T. <to...@cq...>]

I compiled cppunit 1.8 (gnu 2.95.2) and tried to use on UnixWare 7.1.0 and
have the following problem.
Tried the cookbook example and my program core dumps.  I narrowed the
problem down to the delete of the TestFixture class.  If I write a basic
program that just instantiates a TestFixture object (with new) and then I
delete with 'delete'.  I get a Segmentation fault.
Any ideas?
Tom Tegeler
CQG, Inc.
1050 17th St., Suite 2000
Denver, CO 80265
email: to...@cq...
Tel: (720) 904 - 3018, Fax (720) 904-2991

Re: [Cppunit-devel] Improving CppUnit portability

[Volker B. <boe...@we...>]

On Wed, 10 Jul 2002, Baptiste Lepilleur wrote:

>     CppUnit is getting close to having a stable core. I'd like to start
> working in an area that has not been really tackled yet: portability.
> 
>     First, I'd like to start making up a list of things that need to be done
> to make CppUnit more portable. I know some facts, but I hardly have enough
> experience to know every compilers oddities. Also, I'd like to get feedback
> on your experience in solving some of those issues.

I find ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) a very good
source on many portability issues. ACE runs on a number of platforms
I'ld never like to work on, namely compilers missing namespace or even
exception support. ACE uses a lot of preprocessor macros to hide most
of the platform differences. I think that's fine given that C++ is not
as portable as Java (at least as it would be without the preprocessor
trickery...).

See e.g. how the configuration item ACE_HAS_ANSI_CASTS from

  http://cvs.doc.wustl.edu/ace-cvs.cgi/ACE_wrappers/ace/config-g++-common.h

is used in

  http://cvs.doc.wustl.edu/ace-cvs.cgi/ACE_wrappers/ace/config-all.h

to define the macro ACE_const_cast(TYPE, EXPR) which expands to the
proper const_cast<> on platforms which support it and to old style
cast only where necessary.

Regards,
Volker
-- 
Volker Boerchers, boe...@we...

Re: [Cppunit-devel] Improving CppUnit portability

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

Finaly done with most of the change. The trickest was getting around the
need to provide the STL allocator for compiler that do not support default
template parameter.

Curious may give a look to the new CodingGuideLines.txt file in CppUnit root
directory to have an idea of what is involved.

The only things left to deal with is TestCaller default template parameter.

Comments are welcome,
Baptiste.


----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: <cpp...@li...>
Sent: Thursday, July 11, 2002 6:42 PM
Subject: Re: [Cppunit-devel] Improving CppUnit portability


> ----- Original Message -----
> From: "Baptiste Lepilleur" <gai...@fr...>
> To: <cpp...@li...>
> Sent: Wednesday, July 10, 2002 8:45 PM
> Subject: [Cppunit-devel] Improving CppUnit portability
>
>
> >     - Templatized member functions.
> >         Solved. TestSuiteBuilder::addTestCallerForException() has been
> > removed.
>
>     Forgot another item related to template:
>
>     - Default template argument
>         Issue: TestCaller use a default template argument to filter no
> exception.
>         Solution: should be solved when the following item of the TODO
list
> is done:
>
>             Provide a mean for the user to catch 'custom' exception in
> TestCase::run (exception that do not subclass std::exception, such as MFC
> CException, or RogueWave RWXMsg).
>
>         TestCaller will probably not need to test for expected
exception...

---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/

RE: [Cppunit-devel] REQUEST: throw user-defined errors in setUp() and tearDown()

[Pedro F. <ped...@in...>]

> -----Original Message-----
> From: cpp...@li...=20
> [mailto:cpp...@li...] On Behalf=20
> Of Michel Armin
> Sent: quinta-feira, 11 de Julho de 2002 8:23
> To: cpp...@li...
> Subject: RE: [Cppunit-devel] REQUEST: throw user-defined=20
> errors in setUp() and tearDown()
>=20
>=20
> Is there a reason why we do not support assertion in setUp()=20
> and tearDown()? The code could be easily modified to support this.
>=20
> IMHO the general question is, what should be done in setUp()=20
> and tearDown() respectively. Personally, I use them to=20
> provide everything that is common to all test methods in a=20
> class. This also includes setting up a particular state of my=20
> (product code) environment that is a precondition for all the=20
> tests in a testcase class. And of course, this will lead to=20
> code that might fail (for whatever reason). Therefore I like=20
> the idea of being able to have asserts in the setUp() and=20
> tearDown() methods, because these would lead to a more=20
> precise error/failure message, why the test-methods couldn't=20
> be executed successfully. And locating bugs in our programs=20
> is the primary goal of this project, isn't it?
>=20
> Any other opinions?

Agreed.

Cheers,

Pedro
_______________________________________________________
Pedro Alves Ferreira
INESC Porto
Campus da FEUP                   Tel: +351 22 209 42 52
Rua Dr. Roberto Frias, n=BA 378    Fax: +351 22 208 41 72
4200-465 PORTO                 http://www.inescporto.pt
Portugal            mailto:ped...@in...

Re: [Cppunit-devel] Improving CppUnit portability

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

----- Original Message -----
From: "Michel Armin" <Arm...@si...>
To: <cpp...@li...>
Sent: Thursday, July 11, 2002 9:03 AM
Subject: RE: [Cppunit-devel] Improving CppUnit portability


> Hi.
>
> I am not an expert in the field of portability, but I don't like the idea
to
> get rid of the C++ style casts (for instance). These kinds of casts
> (static_cast, dynamic_cast, reinterprete_cast) are more safe with respect
to
> type safety and are - AFAIK - perfectly standarized C++ features. Cutting
> down on C++ features would ulitmately end up in the question whether we'd
> like to implement CppUnit with C++ or with just C.

While I would agree with this for a 'real' project, CppUnit uses only 5
const_cast (to implement constness semantic). Hardly a reason for not
supporting some compilers...

> Coming from a Java playground, I also do not like the idea of introducing
> too many "MACRO-magics", because they just tend to complicate things, for
> example when it comes down to refactoring issues.

I turned down from the CPPUNIT_STD macro (see other post). Remaining macros
will not disturb things that much.

> I'd prefer, if we could concentrate more on getting rid of OS-specifics
than
> on compiler-specifics. Of course, compiler specifics are also a big issue,
> but I hope it will be sufficient, if we support the "more mature" C++
> implementations that already provide the usual common set of features of
> C++.

What are you refering to ? The only OS dependency that I'm aware of is the
DynamicLibraryManager class, which is already portable. The plug-in system
can be made optional if need be. Well, and some part of the build system
(see bug/support), but I can't do much about that.

This leave compiler stuff as the most important thing in the way. As I see
things, it should be possible to compile CppUnit on all the platforms
supported by STLPort which provides exception support and iostream. If they
can get the STL working, we surely can provide something as simple as
CppUnit.

CppUnit should not be the force that will make you choose/upgrade your
compiler. The more people can use CppUnit, the better. If you look hard
enough on the net, you will even find version of CppUnit where the STL where
completly removed. I don't believe we need to go that far (STLPort seems to
be available on a fair amount of platforms), but there is clearly a need...

Baptiste.

>
> Regards
>
> Armin

Re: [Cppunit-devel] REQUEST: throw user-defined errors in setUp() and tearDown()

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

RE: [Cppunit-devel] REQUEST: throw user-defined errors in setUp() and =
tearDown()You can use a TestListener and track startTestRun() and =
endTestRun() to open/close the DB connection.

You still need to find a way to 'pass' it to the test case =
(singleton...).

While I'm at it, does anybody see a need for something like:

void setUp( TestResult *controller )
{
    DbConnection *connection =3D reinterpret_cast<DbConnection *>(=20
                    controller->getNamedResource( "DbConnection1" ) );
}

Baptiste.

  ----- Original Message -----=20
  From: Moran Ben-David=20
  To: 'Michel Armin' ; cpp...@li...=20
  Sent: Thursday, July 11, 2002 4:19 PM
  Subject: RE: [Cppunit-devel] REQUEST: throw user-defined errors in =
setUp() and tearDown()


  While we are on the subject.. Is there a way to set up a TestFixture =
once for all tests?  For example, if my SetUp creates a database =
connection required by the tests in my fixture, it would be ideal if it =
only did so once.

  Moran=20

  -----Original Message-----=20
  From: Michel Armin [mailto:Arm...@si...]=20
  Sent: Thursday, July 11, 2002 3:23 AM=20
  To: cpp...@li...=20
  Subject: RE: [Cppunit-devel] REQUEST: throw user-defined errors in=20
  setUp() and tearDown()=20



  Is there a reason why we do not support assertion in setUp() and =
tearDown()?=20
  The code could be easily modified to support this.=20

  IMHO the general question is, what should be done in setUp() and =
tearDown()=20
  respectively. Personally, I use them to provide everything that is =
common to=20
  all test methods in a class. This also includes setting up a =
particular=20
  state of my (product code) environment that is a precondition for all =
the=20
  tests in a testcase class. And of course, this will lead to code that =
might=20
  fail (for whatever reason). Therefore I like the idea of being able to =
have=20
  asserts in the setUp() and tearDown() methods, because these would =
lead to a=20
  more precise error/failure message, why the test-methods couldn't be=20
  executed successfully. And locating bugs in our programs is the =
primary goal=20
  of this project, isn't it?=20

  Any other opinions?=20




  Regards=20

  Armin.=20

  > -----Original Message-----=20
  > From: Baptiste Lepilleur [mailto:gai...@fr...]=20
  > Sent: Mittwoch, 10. Juli 2002 19:44=20
  > To: John Lam; cpp...@li...=20
  > Subject: Re: [Cppunit-devel] REQUEST: throw user-defined errors in=20
  > setUp() and tearDown()=20
  >=20
  >=20
  > It will be done. It goes along with the following TODO features:=20
  >=20
  >   - Provide a mean for the user to catch 'custom' exception=20
  > in TestCase::run=20
  >     (exception that do not subclass std::exception, such as=20
  > MFC CException,=20
  > or=20
  >     RogueWave RWXMsg).=20
  >=20
  > That feature will likely result in a piece of code that will=20
  > run a specific=20
  > method, catching exceptions and assertion failures. This=20
  > should avoid that=20
  > so very long method...=20
  >=20
  > Though, notes that you usually try to avoid putting assertion=20
  > in setUp() and=20
  > tearDown() (though the memory/resource leaks detection is a=20
  > good candidate=20
  > for a tearDown assertions).=20
  >=20
  > Baptiste.=20
  >=20
  > ----- Original Message -----=20
  > From: "John Lam" <jl...@iu...>=20
  > To: <cpp...@li...>=20
  > Sent: Friday, June 21, 2002 10:57 PM=20
  > Subject: [Cppunit-devel] REQUEST: throw user-defined errors=20
  > in setUp() and=20
  > tearDown()=20
  >=20
  >=20
  > If my setUp() or tearDown() methods fail, I would like to=20
  > have something=20
  > more specific than "setUp() failed ..." showing up in my=20
  > logs. I'd like=20
  > to propose the following change to TestCase.cpp:=20
  >=20
  > It currently reads:=20
  >=20
  >   try {=20
  >   setUp();=20
  >=20
  >   try {=20
  >     runTest();=20
  >   }=20
  >   catch ( Exception &e ) {=20
  >     Exception *copy =3D e.clone();=20
  >     result->addFailure( this, copy );=20
  >   }=20
  >   catch ( std::exception &e ) {=20
  >     result->addError( this, new Exception( e.what() ) );=20
  >   }=20
  >   catch (...) {=20
  >     Exception *e =3D new Exception( "caught unknown exception" );=20
  >     result->addError( this, e );=20
  >   }=20
  >=20
  >   try {=20
  >     tearDown();=20
  >   }=20
  >   catch (...) {=20
  >     result->addError( this, new Exception( "tearDown() failed" )=20
  > );=20
  >   }=20
  >   }=20
  >   catch (...) {=20
  >   result->addError( this, new Exception( "setUp() failed" ) );=20
  >   }=20
  >=20
  > I would like to add:=20
  >=20
  >   catch ( const Exception &e ) {=20
  >     Exception *copy =3D e.clone();=20
  >     result->addError( this, copy );=20
  >   }=20
  >=20
  > to the outer most try block so that I can get more meaningful output =

  > when errors occur.=20
  >=20
  > Similarly, I would like to add the same code to the try block that=20
  > guards the call to tearDown().=20
  >=20
  > Does this sound reasonable to the community?=20
  >=20
  > Cheers,=20
  >=20
  > -John=20
  > http://www.iunknown.com=20
  >=20
  >=20
  >=20
  >=20
  > -------------------------------------------------------=20
  > Sponsored by:=20
  > ThinkGeek at http://www.ThinkGeek.com/=20
  > _______________________________________________=20
  > Cppunit-devel mailing list=20
  > Cpp...@li...=20
  > https://lists.sourceforge.net/lists/listinfo/cppunit-devel=20
  >=20
  >=20
  >=20
  >=20
  > -------------------------------------------------------=20
  > This sf.net email is sponsored by:ThinkGeek=20
  > Two, two, TWO treats in one.=20
  > http://thinkgeek.com/sf=20
  > _______________________________________________=20
  > Cppunit-devel mailing list=20
  > Cpp...@li...=20
  > https://lists.sourceforge.net/lists/listinfo/cppunit-devel=20
  >=20



  -------------------------------------------------------=20
  This sf.net email is sponsored by:ThinkGeek=20
  PC Mods, Computing goodies, cases & more=20
  http://thinkgeek.com/sf=20
  _______________________________________________=20
  Cppunit-devel mailing list=20
  Cpp...@li...=20
  https://lists.sourceforge.net/lists/listinfo/cppunit-devel=20

Re: [Cppunit-devel] REQUEST: throw user-defined errors in setUp() and tearDown()

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

----- Original Message -----
From: "Michel Armin" <Arm...@si...>
To: "'Baptiste Lepilleur'" <gai...@fr...>
Sent: Thursday, July 11, 2002 9:22 AM
Subject: RE: [Cppunit-devel] REQUEST: throw user-defined errors in setUp()
and tearDown()


> Is there a reason why we do not support assertion in setUp() and
tearDown()?
> The code could be easily modified to support this.
No, just never got around doing it.

>
> IMHO the general question is, what should be done in setUp() and
tearDown()
> respectively. Personally, I use them to provide everything that is common
to
> all test methods in a class. This also includes setting up a particular
As far as I know, that is the whole purpose of those methods.

> state of my (product code) environment that is a precondition for all the
> tests in a testcase class. And of course, this will lead to code that
might
> fail (for whatever reason). Therefore I like the idea of being able to
have
> asserts in the setUp() and tearDown() methods, because these would lead to
a
> more precise error/failure message, why the test-methods couldn't be
> executed successfully. And locating bugs in our programs is the primary
goal
> of this project, isn't it?
You can still use assertion, you just won't get the failure detail (at the
current time).

Baptiste.

Re: [Cppunit-devel] Improving CppUnit portability

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

----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: <cpp...@li...>
Sent: Wednesday, July 10, 2002 8:45 PM
Subject: [Cppunit-devel] Improving CppUnit portability


>     - Templatized member functions.
>         Solved. TestSuiteBuilder::addTestCallerForException() has been
> removed.

    Forgot another item related to template:

    - Default template argument
        Issue: TestCaller use a default template argument to filter no
exception.
        Solution: should be solved when the following item of the TODO list
is done:

            Provide a mean for the user to catch 'custom' exception in
TestCase::run (exception that do not subclass std::exception, such as MFC
CException, or RogueWave RWXMsg).

        TestCaller will probably not need to test for expected exception...

>     - STL may not be in ::std namespace.
>         I remember someone saying the issue was partially solved doing a :
>         #define std
>         How well does this works ?

    I looked at STLPort (http://stlport.org/) some and they do just that
(for lowly conformant compiler). So I'll go that way, it keep the code
'clean'. I'll just add an epilog header which will restore 'std' to whatever
is was before it was defined by CppUnit.

>     - mutable keyword (?)
>         Only used in MockTestCase of cppunit test suite. Easily removed.
        Done. Use const_cast now.

>     - C++ cast (const_cast ...)
>         Easily solved (a few occurences of const_cast). Can be convert to
> C-style cast.
        Done. Use a macro that expands to const_cast if possible or do a
C-style cast (there was just about 5 occurences).

    Baptiste.

RE: [Cppunit-devel] REQUEST: throw user-defined errors in setUp() and tearDown()

[Moran Ben-D. <mbe...@ii...>]

While we are on the subject.. Is there a way to set up a TestFixture once
for all tests?  For example, if my SetUp creates a database connection
required by the tests in my fixture, it would be ideal if it only did so
once.

Moran

-----Original Message-----
From: Michel Armin [mailto:Arm...@si...]
Sent: Thursday, July 11, 2002 3:23 AM
To: cpp...@li...
Subject: RE: [Cppunit-devel] REQUEST: throw user-defined errors in
setUp() and tearDown()


Is there a reason why we do not support assertion in setUp() and tearDown()?
The code could be easily modified to support this.

IMHO the general question is, what should be done in setUp() and tearDown()
respectively. Personally, I use them to provide everything that is common to
all test methods in a class. This also includes setting up a particular
state of my (product code) environment that is a precondition for all the
tests in a testcase class. And of course, this will lead to code that might
fail (for whatever reason). Therefore I like the idea of being able to have
asserts in the setUp() and tearDown() methods, because these would lead to a
more precise error/failure message, why the test-methods couldn't be
executed successfully. And locating bugs in our programs is the primary goal
of this project, isn't it?

Any other opinions?



Regards

Armin.

> -----Original Message-----
> From: Baptiste Lepilleur [mailto:gai...@fr...]
> Sent: Mittwoch, 10. Juli 2002 19:44
> To: John Lam; cpp...@li...
> Subject: Re: [Cppunit-devel] REQUEST: throw user-defined errors in
> setUp() and tearDown()
> 
> 
> It will be done. It goes along with the following TODO features:
> 
>   - Provide a mean for the user to catch 'custom' exception 
> in TestCase::run
>     (exception that do not subclass std::exception, such as 
> MFC CException,
> or
>     RogueWave RWXMsg).
> 
> That feature will likely result in a piece of code that will 
> run a specific
> method, catching exceptions and assertion failures. This 
> should avoid that
> so very long method...
> 
> Though, notes that you usually try to avoid putting assertion 
> in setUp() and
> tearDown() (though the memory/resource leaks detection is a 
> good candidate
> for a tearDown assertions).
> 
> Baptiste.
> 
> ----- Original Message -----
> From: "John Lam" <jl...@iu...>
> To: <cpp...@li...>
> Sent: Friday, June 21, 2002 10:57 PM
> Subject: [Cppunit-devel] REQUEST: throw user-defined errors 
> in setUp() and
> tearDown()
> 
> 
> If my setUp() or tearDown() methods fail, I would like to 
> have something
> more specific than "setUp() failed ..." showing up in my 
> logs. I'd like
> to propose the following change to TestCase.cpp:
> 
> It currently reads:
> 
>   try {
>   setUp();
> 
>   try {
>     runTest();
>   }
>   catch ( Exception &e ) {
>     Exception *copy = e.clone();
>     result->addFailure( this, copy );
>   }
>   catch ( std::exception &e ) {
>     result->addError( this, new Exception( e.what() ) );
>   }
>   catch (...) {
>     Exception *e = new Exception( "caught unknown exception" );
>     result->addError( this, e );
>   }
> 
>   try {
>     tearDown();
>   }
>   catch (...) {
>     result->addError( this, new Exception( "tearDown() failed" )
> );
>   }
>   }
>   catch (...) {
>   result->addError( this, new Exception( "setUp() failed" ) );
>   }
> 
> I would like to add:
> 
>   catch ( const Exception &e ) {
>     Exception *copy = e.clone();
>     result->addError( this, copy );
>   }
> 
> to the outer most try block so that I can get more meaningful output
> when errors occur.
> 
> Similarly, I would like to add the same code to the try block that
> guards the call to tearDown().
> 
> Does this sound reasonable to the community?
> 
> Cheers,
> 
> -John
> http://www.iunknown.com
> 
> 
> 
> 
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Two, two, TWO treats in one.
> http://thinkgeek.com/sf
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases & more
http://thinkgeek.com/sf
_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

RE: [Cppunit-devel] REQUEST: throw user-defined errors in setUp() and tearDown()

[Michel A. <Arm...@si...>]

Is there a reason why we do not support assertion in setUp() and tearDown()?
The code could be easily modified to support this.

IMHO the general question is, what should be done in setUp() and tearDown()
respectively. Personally, I use them to provide everything that is common to
all test methods in a class. This also includes setting up a particular
state of my (product code) environment that is a precondition for all the
tests in a testcase class. And of course, this will lead to code that might
fail (for whatever reason). Therefore I like the idea of being able to have
asserts in the setUp() and tearDown() methods, because these would lead to a
more precise error/failure message, why the test-methods couldn't be
executed successfully. And locating bugs in our programs is the primary goal
of this project, isn't it?

Any other opinions?



Regards

Armin.

> -----Original Message-----
> From: Baptiste Lepilleur [mailto:gai...@fr...]
> Sent: Mittwoch, 10. Juli 2002 19:44
> To: John Lam; cpp...@li...
> Subject: Re: [Cppunit-devel] REQUEST: throw user-defined errors in
> setUp() and tearDown()
> 
> 
> It will be done. It goes along with the following TODO features:
> 
>   - Provide a mean for the user to catch 'custom' exception 
> in TestCase::run
>     (exception that do not subclass std::exception, such as 
> MFC CException,
> or
>     RogueWave RWXMsg).
> 
> That feature will likely result in a piece of code that will 
> run a specific
> method, catching exceptions and assertion failures. This 
> should avoid that
> so very long method...
> 
> Though, notes that you usually try to avoid putting assertion 
> in setUp() and
> tearDown() (though the memory/resource leaks detection is a 
> good candidate
> for a tearDown assertions).
> 
> Baptiste.
> 
> ----- Original Message -----
> From: "John Lam" <jl...@iu...>
> To: <cpp...@li...>
> Sent: Friday, June 21, 2002 10:57 PM
> Subject: [Cppunit-devel] REQUEST: throw user-defined errors 
> in setUp() and
> tearDown()
> 
> 
> If my setUp() or tearDown() methods fail, I would like to 
> have something
> more specific than "setUp() failed ..." showing up in my 
> logs. I'd like
> to propose the following change to TestCase.cpp:
> 
> It currently reads:
> 
>   try {
>   setUp();
> 
>   try {
>     runTest();
>   }
>   catch ( Exception &e ) {
>     Exception *copy = e.clone();
>     result->addFailure( this, copy );
>   }
>   catch ( std::exception &e ) {
>     result->addError( this, new Exception( e.what() ) );
>   }
>   catch (...) {
>     Exception *e = new Exception( "caught unknown exception" );
>     result->addError( this, e );
>   }
> 
>   try {
>     tearDown();
>   }
>   catch (...) {
>     result->addError( this, new Exception( "tearDown() failed" )
> );
>   }
>   }
>   catch (...) {
>   result->addError( this, new Exception( "setUp() failed" ) );
>   }
> 
> I would like to add:
> 
>   catch ( const Exception &e ) {
>     Exception *copy = e.clone();
>     result->addError( this, copy );
>   }
> 
> to the outer most try block so that I can get more meaningful output
> when errors occur.
> 
> Similarly, I would like to add the same code to the try block that
> guards the call to tearDown().
> 
> Does this sound reasonable to the community?
> 
> Cheers,
> 
> -John
> http://www.iunknown.com
> 
> 
> 
> 
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Two, two, TWO treats in one.
> http://thinkgeek.com/sf
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

RE: [Cppunit-devel] Improving CppUnit portability

[Michel A. <Arm...@si...>]

Hi.

I am not an expert in the field of portability, but I don't like the idea to
get rid of the C++ style casts (for instance). These kinds of casts
(static_cast, dynamic_cast, reinterprete_cast) are more safe with respect to
type safety and are - AFAIK - perfectly standarized C++ features. Cutting
down on C++ features would ulitmately end up in the question whether we'd
like to implement CppUnit with C++ or with just C.

Coming from a Java playground, I also do not like the idea of introducing
too many "MACRO-magics", because they just tend to complicate things, for
example when it comes down to refactoring issues.

I'd prefer, if we could concentrate more on getting rid of OS-specifics than
on compiler-specifics. Of course, compiler specifics are also a big issue,
but I hope it will be sufficient, if we support the "more mature" C++
implementations that already provide the usual common set of features of
C++.

Regards

Armin

> -----Original Message-----
> From: Baptiste Lepilleur [mailto:gai...@fr...]
> Sent: Mittwoch, 10. Juli 2002 20:45
> To: cpp...@li...
> Subject: [Cppunit-devel] Improving CppUnit portability
> 
> 
>     CppUnit is getting close to having a stable core. I'd 
> like to start
> working in an area that has not been really tackled yet: portability.
> 
>     First, I'd like to start making up a list of things that 
> need to be done
> to make CppUnit more portable. I know some facts, but I 
> hardly have enough
> experience to know every compilers oddities. Also, I'd like 
> to get feedback
> on your experience in solving some of those issues.
> 
>     Here is a list of common portability issues I came up with:
> 
>     - Templatized member functions.
>         Solved. TestSuiteBuilder::addTestCallerForException() has been
> removed.
> 
>     - STL may not be in ::std namespace.
>         I remember someone saying the issue was partially 
> solved doing a :
>         #define std
>         How well does this works ?
> 
>         The solution I came up with is introducing a macro that will
> decorate a name with 'std' depending on the configuration:
>         #if defined( CPPUNIT_HAVE_STD_NAMESPACE )
>         #  define CPPUNIT_STD( symbol ) std::symbol
>         #else
>         #  define CPPUNIT_STD( symbol ) symbol
>         #end
> 
>         While I think this would work (does anybody see an issue with
> that?), it makes the code less readable. Does anyone have an 
> alternative ?
> 
>     - mutable keyword (?)
>         Only used in MockTestCase of cppunit test suite. 
> Easily removed.
> 
>     - C++ cast (const_cast ...)
>         Easily solved (a few occurences of const_cast). Can 
> be convert to
> C-style cast.
> 
>     - namespace
>        CppUnit requires the use of namespace as most of the library is
> placed inside the CppUnit namespace.
> 
>         It should be possible to make that namespace optional 
> by using a
> macro similar to CPPUNIT_STD (see above), as well as other 
> macros to begin
> and end CppUnit namespace declaration.
> 
>         A remaining issue would be the TestAssert namespace. It use a
> templatized functions. Putting that function in a struct to 
> 'simulate' the
> namespace would introduce a templatized methods (which is a 
> big no no). This
> function would need to be moved into the global scope.
> 
>     - std::vector.at()
>         Not supported by some (all?) implentation of g++ STL.
>         Solved (not used).
> 
>     Well, that's all I can come up with at the moment. Please 
> let me know of
> other issues you know of, or problem you see in the proposed solution.
> 
>     Thanks in advance,
>     Baptiste.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Two, two, TWO treats in one.
> http://thinkgeek.com/sf
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

Re: [Cppunit-devel] standard way to handle test data

[FUKUDA F. <ff...@nt...>]

>I'm looking for a standard way for making my TestFixtures data driven.  I've
>read some suggestions about a TextContext class and seen JTestCase
>(http://jtestcase.sourceforge.net/).. Rather than write my own implemention
>of one or more of these concepts for CppUnit, I'd rather use a popular
>implemention.  Is there one?

I'm now making a class CppTestCase(JTestCase C++ port) using apache-Xerces.
not so hard to implement.

-----:-----:-----:-----:-----:-----:-----:-----:-----:-----
FUKUDA (episteme) Fumiki -- magical, but never a magic...

RE: [Cppunit-devel] Debug vs. release builds of CppUnit

[Moran Ben-D. <mbe...@ii...>]

I actually run in both.. especially my performance tests.

-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: Wednesday, July 10, 2002 1:36 PM
To: John Lam; cpp...@li...
Subject: Re: [Cppunit-devel] Debug vs. release builds of CppUnit


I do both, though I mostly use Debug build (when failure cause is not
obvious, I use the debugger to quickly pin-point the cause). Still, I
regularly run the tests in a Release build. This helps spot problems that
might result from compiler optimizations, and the 'release' memory model.

Baptiste.

----- Original Message -----
From: "John Lam" <jl...@iu...>
To: <cpp...@li...>
Sent: Monday, June 24, 2002 6:24 AM
Subject: [Cppunit-devel] Debug vs. release builds of CppUnit


Do most folks run their unit tests using release build settings or debug
build settings? Just curious ...

Cheers,

-John
http://www.iunknown.com




-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf
_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel

RE: [Cppunit-devel] standard way to handle test data

[Moran Ben-D. <mbe...@ii...>]

TestContext to me would be a class that would be passed to Tests each time
they are run.  The Test receiving the context would use it to extract data
necessary for it's test.
 
In my search for separating the data (e.g. primary keys of rows being pulled
from the database, etc.) from my Test Fixture code.. I came accross this:
 
http://c2.com/cgi/wiki?TestDriver <http://c2.com/cgi/wiki?TestDriver> 
 
This page mentions the TestContext class for encapsulating the data required
by a test.. I'm not 100% clear on how I'd like to data-drive my TestFixtures
however, I know I need to as currently I'm hardcoding the, for example,
database primary keys I'm trying to pull from the db to test my querying
code.
 
Forgive my ignorance.. but are you on the cppunit development team?
Moran

-----Original Message-----
From: Baptiste Lepilleur [mailto:gai...@fr...]
Sent: Wednesday, July 10, 2002 1:32 PM
To: Moran Ben-David; cpp...@li...
Subject: Re: [Cppunit-devel] standard way to handle test data


Could you explain shortly what is that TextContext class ? 
 
Recently, I was thinking about passing the TestResult to the setUp() and
tearDown() methods. I can be done without too much trouble, but I still
haven't come up with some really good reason (might change though).
 
Baptiste.

----- Original Message ----- 
From: Moran  <mailto:mbe...@ii...> Ben-David 
To: 'cpp...@li...'
<mailto:'cpp...@li...'>  
Sent: Sunday, July 07, 2002 4:07 AM
Subject: [Cppunit-devel] standard way to handle test data


Hi. 

I'm looking for a standard way for making my TestFixtures data driven.  I've
read some suggestions about a TextContext class and seen JTestCase (
http://jtestcase.sourceforge.net/ <http://jtestcase.sourceforge.net/> )..
Rather than write my own implemention of one or more of these concepts for
CppUnit, I'd rather use a popular implemention.  Is there one?

Thanks, 
Moran 

---------------------|||| ii3 | 
Moran Ben-David 
ii3 Inc. 
t)  416.595.5232 x294 
f)  416.595.5224 
e)  mbe...@ii... 
i)   < http://www.ii3.com/ <http://www.ii3.com/> > 

--------------- eBusiness.  Your Vision Here. 

[Cppunit-devel] Improving CppUnit portability

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

    CppUnit is getting close to having a stable core. I'd like to start
working in an area that has not been really tackled yet: portability.

    First, I'd like to start making up a list of things that need to be done
to make CppUnit more portable. I know some facts, but I hardly have enough
experience to know every compilers oddities. Also, I'd like to get feedback
on your experience in solving some of those issues.

    Here is a list of common portability issues I came up with:

    - Templatized member functions.
        Solved. TestSuiteBuilder::addTestCallerForException() has been
removed.

    - STL may not be in ::std namespace.
        I remember someone saying the issue was partially solved doing a :
        #define std
        How well does this works ?

        The solution I came up with is introducing a macro that will
decorate a name with 'std' depending on the configuration:
        #if defined( CPPUNIT_HAVE_STD_NAMESPACE )
        #  define CPPUNIT_STD( symbol ) std::symbol
        #else
        #  define CPPUNIT_STD( symbol ) symbol
        #end

        While I think this would work (does anybody see an issue with
that?), it makes the code less readable. Does anyone have an alternative ?

    - mutable keyword (?)
        Only used in MockTestCase of cppunit test suite. Easily removed.

    - C++ cast (const_cast ...)
        Easily solved (a few occurences of const_cast). Can be convert to
C-style cast.

    - namespace
       CppUnit requires the use of namespace as most of the library is
placed inside the CppUnit namespace.

        It should be possible to make that namespace optional by using a
macro similar to CPPUNIT_STD (see above), as well as other macros to begin
and end CppUnit namespace declaration.

        A remaining issue would be the TestAssert namespace. It use a
templatized functions. Putting that function in a struct to 'simulate' the
namespace would introduce a templatized methods (which is a big no no). This
function would need to be moved into the global scope.

    - std::vector.at()
        Not supported by some (all?) implentation of g++ STL.
        Solved (not used).

    Well, that's all I can come up with at the moment. Please let me know of
other issues you know of, or problem you see in the proposed solution.

    Thanks in advance,
    Baptiste.

[Cppunit-devel] CppUnit 1.9.8 compilation status...

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

I'd like to know if there was any compilation issues (Unix, BeOs...) with
CppUnit 1.9.8 (did not get much feedback).

Thanks in advance,
Baptiste.

Re: [Cppunit-devel] REQUEST: throw user-defined errors in setUp() and tearDown()

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

It will be done. It goes along with the following TODO features:

  - Provide a mean for the user to catch 'custom' exception in TestCase::run
    (exception that do not subclass std::exception, such as MFC CException,
or
    RogueWave RWXMsg).

That feature will likely result in a piece of code that will run a specific
method, catching exceptions and assertion failures. This should avoid that
so very long method...

Though, notes that you usually try to avoid putting assertion in setUp() and
tearDown() (though the memory/resource leaks detection is a good candidate
for a tearDown assertions).

Baptiste.

----- Original Message -----
From: "John Lam" <jl...@iu...>
To: <cpp...@li...>
Sent: Friday, June 21, 2002 10:57 PM
Subject: [Cppunit-devel] REQUEST: throw user-defined errors in setUp() and
tearDown()


If my setUp() or tearDown() methods fail, I would like to have something
more specific than "setUp() failed ..." showing up in my logs. I'd like
to propose the following change to TestCase.cpp:

It currently reads:

  try {
  setUp();

  try {
    runTest();
  }
  catch ( Exception &e ) {
    Exception *copy = e.clone();
    result->addFailure( this, copy );
  }
  catch ( std::exception &e ) {
    result->addError( this, new Exception( e.what() ) );
  }
  catch (...) {
    Exception *e = new Exception( "caught unknown exception" );
    result->addError( this, e );
  }

  try {
    tearDown();
  }
  catch (...) {
    result->addError( this, new Exception( "tearDown() failed" )
);
  }
  }
  catch (...) {
  result->addError( this, new Exception( "setUp() failed" ) );
  }

I would like to add:

  catch ( const Exception &e ) {
    Exception *copy = e.clone();
    result->addError( this, copy );
  }

to the outer most try block so that I can get more meaningful output
when errors occur.

Similarly, I would like to add the same code to the try block that
guards the call to tearDown().

Does this sound reasonable to the community?

Cheers,

-John
http://www.iunknown.com




-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cppunit-devel