If you're planning on introducing more testing like you have done for
TCPConnection, may I recommend UnitTest++,
I would be very pleased if you introduced unit testing as it would allow
more freedom for those who want to help develop the library without
having to worry about whether they've broken anything else - I can't
speak for anyone else on this but I tend to use the library in the same
way on each project so the chances of me finding out that I've broken
features I don't make regular use of are pretty low. I know there's the
examples and your new dtest thingy but I'm not sure they offer the same
level of confidence as a screen which says "Success: 2000 tests passed".
You could then review patches solely on the basis of whether they're
actually any good for the library as opposed to trying to determine
whether it works without breaking anything. Plus it would be easier for
end users to check if the library works on their platform :) Maybe this
would take some pressure off you as well.
I'm probably preaching to the choir on this (sorry!) but I really think
this would be a strong move forward and as you've said previously, now
is the time for big changes to happen.
PS For anyone who's going to scream "Unit test a database? You fool.",
I'm not talking about having the tests actually running against a real
database server as we're testing mysql++, not mysql server. Where
appropriate, you could create a mock object to represent the database
server and then check that mysql++ has done what it should have done
i.e. sent the correct query to the database:
CHECK_EQUAL(testdatabaseserver.GetLastQuery(),"SELECT * FROM `stock`");
As a side effect, this would push the library towards database
independence which is on the wishlist.