Thread: Re: [Cppunit-devel] Most user-friendly version of CppUnit
Brought to you by:
blep
From: Martin L. <mle...@fr...> - 2003-07-29 13:51:02
|
In addition, I'd say that helper macros help a lot when writing a new testMethod, and makes its registration within a TestFixture and the TestFixture into a TestSuite *VERY* easy. Martin Just an illusion, but so good, so nice ! Noel Yap <Noe...@mo...> Sent by: cpp...@li... 28/07/2003 21:40 Please respond to Noel.Yap To: Bob Johnson <bjo...@pc...> cc: cpp...@li..., bjo...@co... Subject: Re: [Cppunit-devel] Most user-friendly version of CppUnit Depending on what you're expecting, I'm not sure you'll be able to get what you want since JUnit uses reflection to "know" the names of your test cases while C++ doesn't have reflection. I think, once you start using CppUnit, it's pretty easy to use. In order to get automagic knowledge of test case names, in our build, I put together a script using typical command-line tools (eg perl, sed, awk, grep) so in practice, it's possible to get what JUnit affords, but it'll take a little more work. HTH, Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Cppunit-devel mailing list Cpp...@li... https://lists.sourceforge.net/lists/listinfo/cppunit-devel |
From: Noel Y. <Noe...@mo...> - 2003-07-29 14:02:18
|
The macros certainly go a long way in making CppUnit a bit more user friendly. Personally, I don't like the macros since: - IIRC, they get in the way of emacs fontification and indentation - they don't conform to our coding standards - I just don't like using macros for code generation purposes, there are better tools out there for this Noel Martin Lescuyer wrote: > > In addition, I'd say that helper macros help a lot when writing a new > testMethod, and makes its registration within a TestFixture and the > TestFixture into a TestSuite *VERY* easy. > Martin > > Just an illusion, but so good, so nice ! > > Noel Yap <Noe...@mo...> > Sent by: cpp...@li... > 28/07/2003 21:40 > Please respond to Noel.Yap > > > To: Bob Johnson <bjo...@pc...> > cc: cpp...@li..., bjo...@co... > Subject: Re: [Cppunit-devel] Most user-friendly version of CppUnit > > Depending on what you're expecting, I'm not sure you'll be able to get > what you want since JUnit uses reflection to "know" the names of your test > cases while C++ doesn't have reflection. > > I think, once you start using CppUnit, it's pretty easy to use. In order > to get automagic knowledge of test case names, in our build, I put > together a script using typical command-line tools (eg perl, sed, awk, > grep) so in practice, it's possible to get > what JUnit affords, but it'll take a little more work. > > HTH, > Noel > -- > NOTICE: If received in error, please destroy and notify sender. Sender > does not waive confidentiality or privilege, and use is prohibited. > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Cppunit-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppunit-devel > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Cppunit-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppunit-devel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. |
From: Baptiste L. <gai...@fr...> - 2003-08-12 07:25:21
|
----- Original Message ----- From: "Noel Yap" <Noe...@mo...> To: "Martin Lescuyer" <mle...@fr...> Cc: <bjo...@co...>; "Bob Johnson" <bjo...@pc...>; <cpp...@li...> Sent: Tuesday, July 29, 2003 4:02 PM Subject: Re: [Cppunit-devel] Most user-friendly version of CppUnit > The macros certainly go a long way in making CppUnit a bit more user friendly. > > Personally, I don't like the macros since: > - IIRC, they get in the way of emacs fontification and indentation Surely someone fixed this parsing issue. At worth, CPPUNIT macros should be consider as function declaration with omitted return type. But this kind of macros is already specific to CppUnit. A few libraries with similar macros that come to mind: Qt, WxWindow, MFC. Fairly common stuffs. > - they don't conform to our coding standards > - I just don't like using macros for code generation purposes, there are better tools out there for this Those macros are designed to remove code duplication. They also help isolate the test code from the underlying framework (switching to cppunit v2 will me much simpler if you are using those macro, as it is fairly simple to write an a portability layer for them). I don't know of any better way to 'generate' code than those 'fairly' simple macro. May be you would like to share (cppunit v2 is relying on a similar scheme at the time). > > Noel > > Martin Lescuyer wrote: > > > > In addition, I'd say that helper macros help a lot when writing a new > > testMethod, and makes its registration within a TestFixture and the > > TestFixture into a TestSuite *VERY* easy. > > Martin > > > > Just an illusion, but so good, so nice ! > > > > Noel Yap <Noe...@mo...> > > Sent by: cpp...@li... > > 28/07/2003 21:40 > > Please respond to Noel.Yap > > > > > > To: Bob Johnson <bjo...@pc...> > > cc: cpp...@li..., bjo...@co... > > Subject: Re: [Cppunit-devel] Most user-friendly version of CppUnit > > > > Depending on what you're expecting, I'm not sure you'll be able to get > > what you want since JUnit uses reflection to "know" the names of your test > > cases while C++ doesn't have reflection. > > > > I think, once you start using CppUnit, it's pretty easy to use. In order > > to get automagic knowledge of test case names, in our build, I put > > together a script using typical command-line tools (eg perl, sed, awk, > > grep) so in practice, it's possible to get > > what JUnit affords, but it'll take a little more work. > > > > HTH, > > Noel |
From: Duane M. <dua...@ma...> - 2003-08-12 15:16:52
|
--- At Tue, 12 Aug 2003 09:31:18 +0200, Baptiste Lepilleur wrote: >> - I just don't like using macros for code generation purposes, there are >better tools out there for this > >Those macros are designed to remove code duplication. They also help isolate >the test code from the underlying framework (switching to cppunit v2 will me >much simpler if you are using those macro, as it is fairly simple to write >an a portability layer for them). > >I don't know of any better way to 'generate' code than those 'fairly' simple >macro. May be you would like to share (cppunit v2 is relying on a similar >scheme at the time). This comment greatly concerns me about the future of CppUnit. I hope that there is simply a misunderstanding of what the need for these macros are. The macros are _not_ needed to remove code duplication. Simple functions can do that just fine. Template functions and classes can do it if there are type or naming problems. The real reason I see for using the macros is the necessity of including __FILE__ and __LINE__ (and sometimes __func__) in the exception and error reporting. There is no good way of getting this information easily out of the code without macros (aside from the user actually typing them). The only macro's I use are the ones that involve the actuall testing. I dont use any of the other macros so maybe I'm not a typical user. ...Duane |
From: Baptiste L. <gai...@fr...> - 2003-09-09 00:48:01
|
----- Original Message ----- From: "Duane Murphy" <dua...@ma...> To: "Baptiste Lepilleur" <gai...@fr...>; "CppUnit Developers" <cpp...@li...> Sent: Tuesday, August 12, 2003 5:14 PM Subject: Re: [Cppunit-devel] Most user-friendly version of CppUnit > --- At Tue, 12 Aug 2003 09:31:18 +0200, Baptiste Lepilleur wrote: > > >> - I just don't like using macros for code generation purposes, there are > >better tools out there for this > > > >Those macros are designed to remove code duplication. They also help isolate > >the test code from the underlying framework (switching to cppunit v2 will me > >much simpler if you are using those macro, as it is fairly simple to write > >an a portability layer for them). > > > >I don't know of any better way to 'generate' code than those 'fairly' simple > >macro. May be you would like to share (cppunit v2 is relying on a similar > >scheme at the time). > > This comment greatly concerns me about the future of CppUnit. I hope that > there is simply a misunderstanding of what the need for these macros are. The helper macros are more akin to a facade for CppUnit features. That why newbies like them. But they are helper and they will remain that way. All features, with the exception of fixture class inheritance (at the current time), will always be available from the framework. > The macros are _not_ needed to remove code duplication. Simple functions > can do that just fine. Template functions and classes can do it if there > are type or naming problems. You can not remove the duplication of 'testName', &Class::testMember without macro. This usually involve some copy/paste which you can easily mess up with. Even worth, you could use some non portable member reference (VC6 allow creating the function pointer using &testMember). But it's true that the TestCaller stuff can be simplified using template generator function. Also, because the macro provide a simple facade to the unit testing framework, it is fairly easy to switch from one framework to another one (this also apply to cppunit v2). > The real reason I see for using the macros is the necessity of including > __FILE__ and __LINE__ (and sometimes __func__) in the exception and error > reporting. There is no good way of getting this information easily out of > the code without macros (aside from the user actually typing them). > > The only macro's I use are the ones that involve the actuall testing. I > dont use any of the other macros so maybe I'm not a typical user. I guess so. Most people seems to like the simplicity provided by the macro. Though, some of them should probably removed (like CPPUNIT_TEST_EXECPTION...) and be replaced by a corresponding assertion macro. Also, they still need more flexibility. Baptiste. > ...Duane |
From: Noel Y. <Noe...@mo...> - 2003-08-12 15:46:31
|
Baptiste Lepilleur wrote: > Surely someone fixed this parsing issue. At worth, CPPUNIT macros should be > consider as function declaration with omitted return type. But this kind of > macros is already specific to CppUnit. A few libraries with similar macros > that come to mind: Qt, WxWindow, MFC. Fairly common stuffs. Even if someone did fix the emacs parsing, I consider it a hack that'll work so long as CppUnit doesn't change or add macro names. > I don't know of any better way to 'generate' code than those 'fairly' simple > macro. May be you would like to share (cppunit v2 is relying on a similar > scheme at the time). I can't send the entire script, but here's a snippet (which may not make sense outside the context of the rest of it): for test_header in $$test_headers; \ do \ test_fqbn=`echo $$test_header | sed -e 's/.*\/lib\/\\(.*\\)\\.H/ \\1/g' -e 's/\//::/g'`; \ grep 'void *test[a-zA-Z0-9_][a-zA-Z0-9_]* *( *)' $$test_header \ | sed -e 's/.* \(test[^ (]*\).*/\1/' \ | while read t; \ do \ echo " testSuite->addTest("; \ echo " new CppUnit::TestCaller< $$test_fqcn > ("; \ echo " \"$$test_fqbn::$$t\","; \ echo " &$$test_fqcn::$$t) );"; \ done; \ done; \ It may look strange since it's a script within a makefile. HTH, Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. |
From: Baptiste L. <gai...@fr...> - 2003-09-09 00:13:36
|
----- Original Message ----- From: "Noel Yap" <Noe...@mo...> To: "Baptiste Lepilleur" <gai...@fr...> Cc: <cpp...@li...> Sent: Tuesday, August 12, 2003 5:39 PM Subject: Re: [Cppunit-devel] Most user-friendly version of CppUnit > Baptiste Lepilleur wrote: > > Surely someone fixed this parsing issue. At worth, CPPUNIT macros should be > > consider as function declaration with omitted return type. But this kind of > > macros is already specific to CppUnit. A few libraries with similar macros > > that come to mind: Qt, WxWindow, MFC. Fairly common stuffs. > > Even if someone did fix the emacs parsing, I consider it a hack that'll work so long as CppUnit doesn't change or add macro names. You should not need to rely on the macro name to parse this. A structure of the forms "id( expression-list);" could be parsed as a function declaration returning int (well, that's how I would do it). As I said this kind of macro is not specific to cppunit. I certainly won't remove those because a text editor can not ident correctly ;-) > > I don't know of any better way to 'generate' code than those 'fairly' simple > > macro. May be you would like to share (cppunit v2 is relying on a similar > > scheme at the time). Which is not portable. It relies on a specific build system, as well as a shell environment. Beginners would probably run away ;-). Also, this slow down the build process. I like being able to run my test plug-in a a few seconds ;-) You might want to look up project cuppa (http://sourceforge.jp/projects/cuppa/) which (I believe) provides a portable implementation to do that. > I can't send the entire script, but here's a snippet (which may not make sense outside the context of the rest of it): > > for test_header in $$test_headers; \ > do \ > test_fqbn=`echo $$test_header | sed -e 's/.*\/lib\/\\(.*\\)\\.H/ > \\1/g' -e 's/\//::/g'`; \ > grep 'void *test[a-zA-Z0-9_][a-zA-Z0-9_]* *( *)' $$test_header > \ > | sed -e 's/.* \(test[^ (]*\).*/\1/' \ > | while read t; \ > do \ > echo " testSuite->addTest("; \ > echo " new CppUnit::TestCaller< $$test_fqcn > > ("; \ > echo " \"$$test_fqbn::$$t\","; \ > echo " &$$test_fqcn::$$t) );"; \ > done; \ > done; \ > > It may look strange since it's a script within a makefile. > > HTH, > Noel > -- > NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. |