List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:July 20 2007 12:27pm
Subject:Re: Connection class reorg in a testable state
View as plain text  
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.
Thread
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