ISerializable - Roy Osherove's Blog

Here are my thoughts on the subject from a while back...

http://blogs.geekdojo.net/pdbartlett/archive/2004/03/09/1339.aspx

Here's one other C++ unit testing framework (haven't used any of them so don't know which is best):
http://cpptest.sourceforge.net/

Hey Kyle, thanks! I've checked out Kinook's Visual Build software a while ago and have often compared it with FinalBuilder which I just love. Just wanted to give props to your company for making a powerful product. I just wish it would be more usable and less "macro" oriented.

Roy,

check out Ron Jeffries site, http://www.xprogramming.com/software.htm. There are a bunch of links there to C++ testing frameworks. Also check out CppUnitLite from Michael Feathers. I've used this on a project before, and it worked really well. It's available on the objectmentor.com site someplace.

bab

Well Roy you are right it is more difficult than it should be, but not nearly as difficult as you have describe it! Some of the limitations come from the nativeness of the language itself, for example without reflection you cant have a framework that auto discoverers test functions. Also you cant have mock objects without reflection.

As for refactoring support, there is one tool that I can think of: Xrefactory that integrates well in Emacs, Xemacs and I believe Jedit too. Also there is plan to implement DOM parser in CDT (that has decent support) thus you be able to use Eclipse for refactoring Not that I would need another IDE as I'm an (X)Emacs guy. By the way I also think the Visual Studio 6.0 sucks but there are better options anyway.


There is no need to register testcases manually (although I prefer to do this myself for reasons not presented here): there you can use CPPUNIT_TEST_SUITE_REGISTRATION macro, or just configure your editor template support to add these lines automatically. Also you can very well use fancy GUI runners, as far as I know there is one implemented for windows with MFC and another cross-platform with QT. But then again you-will need command line as for automated continuous builds. Supplied GUI runner example is minimalistic enough for you to use one for your self should you need it.

True that you don't have ant, but you have make, nmake, jam, A-A-P, SCons and lot more of build tools that don't need hairy XML syntax to setup a simple build. As for coverage there is Rational Pure Coverage, tcov, gcov, Dynamic Code Coverage, CTC++, and whole lot more. As for dependency analysis your statement is simply not fare.

Arnold Ewald mentions he has implemented a Mock Objects framework for C++.

>(BTW: Does anyone have any knowledge of the C++ testing frameworks listed here >at the bottom of the page? Got any favorite?)

My favourite C++ testing framework is TUT (which is not listed!), although it won't work with vc 6 nor vs.net 2002 (it requires a strongly template compliant compiler). It works fine with vc 7.1 (vs.net 2003) and as well with other platforms (solaris etc)

It only requires two header files (no lib!) and I find it very easy to setup and use, very lightweight, and its integration in the build cycle is simple.

I posted about it : http://blogs.dotnetguru.org/tbarrere/?title=unit_testing_with_tut&more=1&c=1&tb=1&pb=1

You can download TUT here : http://tut-framework.sourceforge.net/

I'm the development manager seeking agile C++ developers in Toronto.

I wouldn't say that Test Driven Development ("TDD") with C++ is much harder than it should be (although that's true). I would say:

1. Test-driven development of any applications written 5-15 years ago is hard. TDD was not common, and the architectures of legacy applications are not supportive. Even with great tools, it is hard to use TDD on legacy applications.

The connection with C++ is fairly obvious: much of the C++ code out there was first written 5+ years ago.

As a knock-on effect of this, most of the C++ developers kicking around did not employ TDD during their "formative years." As a result, they don't use TDD tools. Try making a TDD C++ tool: you'll find it very hard to get C++ developers to adopt it.

2. Test-driven development of highy OS-initimate applications is hard. Operating system APIs simply aren't written to facilitate test-driven development. That's why WinRunner sucks as a test tool: it's the OS that makes it hard.

Of course, if people were using C++ for three-tier business applications we would find TDD easier. But of course, people aren't writing those applications in C++. People are writing things that are fairly intimate with APIs, and most of these don't facilitate TDD>

Can we factor UIs out and take other steps to make C++ applications easier to test using automation? Of course we can, and we do. But it's inherently harder to do so.

*****

In summary, my experience is that there is a vicious cycle at work: legacy coders (5+ or 10+ years of experience) aren't big on TDD, so the market for TDD is smaller on platforms/languages that have been around longer. This drives fewer tools, which in turn drives lower adoption.

Simultaneously, it's hard work to make API-intimate applications testable. This exerts serious negative pressure on TDD.

p.s. "Hard work"??? I know, just design well from the get-go. This is easy in theory, difficult in practice when the bug list is a mile long, there's a hard cap on a release date next Friday, and the VP of Product Management is drilling down on every developer-hour invested. The "hard work" is often political :-)

p.p.s. Despite my complaining, we're still hard core about agile development and test-driven development. And yes, I do the "hard work" of selling management on the ROI. For example, later this (12/2004) month, we have a consultant coming in to lead a two day CPPUnit workshop.

Although this seems like an easy thing to arrange, I assure you there has been serious due diligence on investing two days for each developer in this training as opposed to doing other work.

It's easy to say "we'll make up the lost time in improved productivity," but in a professional environment you had better be prepared to say "if we don't do the training here is the schedule for what will be developed by when. If we go ahead with the training here are the specific and measurable improvements in dates and/or scope. And here's the objective analysis backing everything up."