Re: Connection class reorg in a testable state

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.

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

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.

Do you need more 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 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.

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