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.
Arnold Ewald mentions he has implemented a Mock Objects framework for C++.
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 :-)