List:MySQL++« Previous MessageNext Message »
From:Joel Fielder Date:July 19 2007 6:12pm
Subject:RE: Connection class reorg in a testable state
View as plain text  
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.

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

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

	std::string sql = "SELECT * FROM `query";
	Query q = connection.Query();
	q << 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.


Connection class reorg in a testable stateWarren Young18 Jul
  • RE: Connection class reorg in a testable stateJoel Fielder18 Jul
    • Re: Connection class reorg in a testable stateWarren Young18 Jul
      • RE: Connection class reorg in a testable stateJoel Fielder19 Jul
        • Re: Connection class reorg in a testable stateWarren Young20 Jul
          • RE: Connection class reorg in a testable stateJoel Fielder20 Jul
            • Re: v3 development planWarren Young20 Jul
          • RE: Connection class reorg in a testable stateJoel Fielder20 Jul