it's not that much.
True for each library you write you need
- a driver file
- at least one "root" TestSuite
These files are pretty constant, only the name of root testsuite has
to be updated, and it's just a per library overhead.
For individual tests you simply write a TestClass which
presents a set of tests, i.e each method of the TestClass
represents a single test.
I don't feel it's that much of an overhead, yes, you have to
organize your tests manually into a hierarchy.
Still, I don't want to miss that feature.
Especially when you have close to 500 tests as with Foundation :-)
But you are absolutely right:
programmers try to minimize code typing where possible.
Switching to another test framework, well, not really.
But automating the code generation for tests, that would be cool.
We do have some scripts already, that at least generate empty hulls
for TestSuites and TestCases (not part of the Poco release though).
Which leaves us only with the implementation of the tests,
and the suite() implementation.
PS: Did you find that page useful?
> I am all for unit testing but my approach is to have 3 files; the header, the associated implementation and one other file - the test harness. Poco seems to require several files and several classes. This seems a bit heavyweight to me and an impediment to adding further classes to Poco. Any thoughts? Peter Sommerlad from the ACCU has written CUTE which aims to simplify writing unit test harnesses. This is like a very cutdown version of CppUnit. I am not completely happy with CUTE either but IMO something very much like it is needed so that unit tests can be easily added to any project, be it Poco or anything else.