RE: Connection class reorg in a testable state

Well I enjoy a challenge, so here goes.

Firstly, to clarify, I didn't realise that dtest was in fact running these other test programs as well - I thought it was just comparing the good known output against the current example program outputs. In my mind that's not quite the same level of confidence as it tests the high level whereas what I'm talking about is the low level granular stuff that you've just introduced.

Despite that, I still think UnitTest++ could bring a lot to the project.

First of all, the mandatory testing issue. I don't really think that's a problem as mostly the people who will be using it are going to be those who are actively contributing to the library i.e. the target audience here is the hackers, not the users. That's not many people compared with the number of people who have problems simply finding readme/google so I don't believe it would generate noise. Additionally, it's quite easy to change the UnitTest++ makefile to remove the building and the running of the test application. I'm pretty sure there's no licensing issue with that and if there is we could submit a patch with a "no-post-build-test" target.

So, I'm not necessarily proposing using it to replace the exercising of the examples - I suppose that's more of an integration test as it's working against a real server. But I am proposing using it for what's currently in the test subdirectory, for these reasons:

1. It's feature rich. Different types of check: CHECK, CHECK_EQUAL, CHECK_CLOSE (floating point comparison), and various versions of CHECK_ARRAY. Also CHECK_THROW to make sure something throws an exception. Unhandled exceptions are automatically reported as a test failure. Test suites and fixtures are both supported. You can create a custom reporter object to specify how the results are displayed.
2. It's cross platform. Claims to be ANSI portable C++ and supports Win32, Linux, and Mac OS X out of the box. Win32 and Linux I can confirm that's true, but I don't have access to a Mac box.
3. It's stable. Because it's pretty much feature complete, there's not many changes going on. And because it's all developed test driven, it rarely breaks. Its mailing list is very quiet which I think is an endorsement of stability, and also a further indication that you can expect not to have any noise on this list because of it.
4. It has no dependencies, so it's easy to build. (It does require sed, rm and mv on Linux etc but surely everyone has those?)
5. It's very easy to use.
6. Its name ends in "++" as well.

You could say that dtest has all of those except for number 1, but I'm not sure there's any reason to re-invent the wheel. Wouldn't it be easier to convert to UnitTest++ rather than spend ages re-implementing all of its nice features? Additionally, I think it would add credibility. People like software that's test driven because it's a real measure of quality, but if you roll your own they might not have quite the same confidence as with something that's in widespread use, even if it's comparable.

> If your concern is that we don't yet have 2000 tests, get coding. :)

Yup, this is a concern, and I do love a juicy target.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek

> I don't see it as a good way to make MySQL++ database-independent.

Well surely if you want to be able to test it and to use it for real, you've got to have a dummy database driver and a real one, and they must expose the same interface (i.e. implement IDatabaseDriver or whatever). Doesn't the writing of tests to check that it sent the right query force the development of the real thing also? If I was going to start database independence, I'd do something like this before even thinking about how I was going to change the library:

TEST(ItRunsTheQuery)
{

	TestDatabaseDriver driver;
	Connection connection(TCPConnection(whatever),driver);

	std::string sql = "SELECT * FROM `query";
	Query q = connection.Query();
	q << sql;
	q.execute();

	CHECK_EQUAL(driver.GetLastQuery(),sql);

This is one of the major benefits of test driven development - the high granularity of the testing forces the removal of dependencies which creates a nice flexible design. For example, it would be nice to remove #include "mysql++.h" from row's header so that when I create a functor which acts on a row, it doesn't have to include the whole of mysql.

End of essay.

Joel

-- 
MySQL++ Mailing List
For list archives: 
http://lists.mysql.com/plusplus
To unsubscribe:    
http://lists.mysql.com/plusplus?unsub=lists@pantek.com