List:MySQL++« Previous MessageNext Message »
From:Joel Fielder Date:July 20 2007 1:57pm
Subject:RE: Connection class reorg in a testable state
View as plain text  
Warren Young wrote:

> Maybe I'm misjudging because of the thin documentation, but it doesn't

> look like it really does all that much.

Well granted, it's only a testing framework.  There's not much more I
can say - maybe spend a couple of hours coding with it and see how you
get on?

> In that case, we'll have feature parity in about another day's
development time.

The developers have spent quite a lot of time on it - even with your
coding skills that seems optimistic!

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

It doesn't work in that way.  There would be two projects - the mysql++
library, and one executable with all the tests in it.  The mysql++
library has no dependency on the test application.  So no CHECK calls in
the library anywhere - you just test the interface does what you expect.

Here's a test application:

#include "UnitTest++/src/unittest++.h"

#include "mysql++.h"

int main(int argc, char *argv[])
{	
	return UnitTest::RunAllTests();
}

TEST(DoesItWork)
{
	CHECK(whatever);
}

> Am I missing some big chunk of value here?

Maybe, as many developers swear by it - I don't write any code without
having a test for it first, although that's just a symptom of deciding
to test first rather than a byproduct of this particular framework.
Again, all I can say is try it out.

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

Tests should be really simple and just exercise the library interface.
If the code doesn't work, it's more likely a problem with the library
rather than the test because the tests will be using the library in the
same way that any client will be.

> it follows that release versions of MySQL++ 
> can't have post-build unit tests turned on.

I'm not sure it would be wise to do that anyway.  I would say that it
should be for hackers use, rather than for regular library users.

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

Yes, but that's testing the hypothetical database server (integration
test), not that the query object is actually sending what it should be
to mysql.

> I think you're overselling test-driven development.  It's quite
possible 
> to have a testable design that still has many dependencies.

I accept what you're saying, but it's the same with anything - the
developer has to have a brain.  But if you don't write any code without
having a test for it, and you refactor appropriately, the low
dependency, granular design will evolve.

I honestly don't think I'm overselling tdd.  We have 100% test coverage,
with high granularity, low dependency code.  Coding test-first is the
only way to get seriously reliable software, even more so in an
environment where anyone can contribute.  Sure, you can add tests later,
but can you ever say with confidence that you have 100% test coverage?
No way.

Anyway, I really think you should at have a go with UnitTest++ and see
how you like it before deciding.

Joel

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