From: Warren Young
Date: July 20 2007 12:27pm
Subject: Re: Connection class reorg in a testable state
List-Archive: http://lists.mysql.com/plusplus/6834
Message-Id: <46A0AA2B.2090602@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Joel Fielder wrote:
>
> 1) It's feature rich.
Maybe I'm misjudging because of the thin documentation, but it doesn't
look like it really does all that much. From a pure feature checklist
standpoint, I think I've managed to nearly match it already.
Let's say I'm not seeing all the value, and that dtest only does half as
much. In that case, we'll have feature parity in about another day's
development time. :)
Unless I'm so very wrong that dtest isn't even half as powerful, all
that's left to argue over are style questions. That's no way to win me
over.
The only possible benefit I can see is that it might make the MySQL++
build process faster. The current test/* scheme makes one executable
for each class of test, which is fairly expensive. One hopes that UT++
will let you scatter CHECK_* calls throughout the library code proper,
saving on at least the linking time for all those little test programs.
So a) is that true?; and b) am I missing some big chunk of value here?
> 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.
You misunderstand my concern about list noise. I don't doubt that UT++
itself is stable. What I doubt is that one can reliably write tests
correctly for a platform you don't use.
If you accept that as true, it follows that release versions of MySQL++
can't have post-build unit tests turned on. Otherwise, you risk
spending more time working on fixes to the test suite to address niggly
platform differences than you gain by making everyone run the test suite.
> 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).
No, not at all.
If database independence ever happens (big "if"), I will call it a
success if the library returns the same database results for a given
query regardless of the database server you point it at. For the
limited goal, the current bmark.txt snapshot scheme suffices.
Put another way, if you say
SELECT name FROM animals WHERE walk LIKE 'duck' AND sound LIKE 'duck'
and get back 'duck', the test passes. A database-independent MySQL++
wouldn't try to paper over meaningful differences between database
servers, so there's a pretty severe limit on how detailed your testing
can be.
> 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.
I think you're overselling test-driven development. It's quite possible
to have a testable design that still has many dependencies.
What test-driven development does is prevent monolithic design, because
it requires granularity. A highly granular design can still be so
deeply hooked into the technologies you're currently using that it's
completely unportable.
The only design benefit you get from test driven development is that
granularity allows you to replace small pieces one at a time, instead of
having to replace everything in one big lump. This makes moving from an
unportable design to a portable one easier. This is not the same thing
as a "removal of dependencies". You still gotta do that work yourself.
> 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.
row.h doesn't include mysql++.h. None of MySQL++'s headers do, on
purpose, because the purpose of mysql++.h is to be a unified interface
to the library for external programs.
I think we should take the v3 opportunity to audit #include use, to
reduce dependencies. It's on the Wishlist now, whether it's what you
meant or not.