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