| Re: [cdt-dev] CppUnit integration |
Many thanks for suggestions.
Well, I think mine was more of a rant than a suggestion, but you're welcome ;-)
JUnit for Java, Mike is also right in mentionning that no standard is available today for C/C++. So why not CppUnit, which concepts are the closest from JUnit (it is the official port to C++).
Because C++ is not Java, and the JUnit concepts are not necessarily the best choices for C++.
Take the Fixture concept, for example, which CppUnit copies pretty much verbatim. Are fixtures, supplying setup/teardown calls around each test, really necessary in a language which supports deterministic destruction? In a language which doesn't force all functions to be class members _anyway_?
We saw something similar with NUnit. NUnit version 1 followed the ugly JUnit idiom of prefixing test function names with "Test", allowing the framework to identify them via reflection. NUnit version 2 realized that hey, we're not writing Java anymore, we can use attributes for this. I think everyone (including Kent Beck) agrees that this adaptation to language idioms is an improvement.
C++ test frameworks face unique tradeoffs. There's no reflection. (You can fake it for Windows by building test suites as DLLs and parsing/demangling the export table, but it's not remotely portable.) So: you can either indulge in evil macro hackery and make tests very very easy to write, or you can be respectable and require a stack of plumbing (register tests with test suite, register suites with testrunner) and make tests very very tedious to write. Personally I lean toward the former - it's not production code, and tedious tests mean fewer tests - but that's just my preference. My point is that there's no consensus on this, and I don't know if there ever will be.
Cheers, MikeP.S. offtopic, but to those of you working on the parser - have you looked at www.gccxml.org? It's a patch to GCC's C++ frontend to output the parse tree as XML, and seems to be the best-kept secret in C++ tool development at the moment.