PSP, XP, TDD and other methodologies for solitary programmers

[John Roth]

"Brad Clements" <bkc at Murkworks.com> wrote in message
news:3e14a219$1_1 at goliath.newsgroups.com...
> _
> "Terry Reedy" <tjreedy at udel.edu> wrote in message
> news:aJWcnRWzQtc7E4mjXTWcqA at comcast.com...
>
> > For those who missed the reference in a recent thread, there is an
> > online PDF prepublication version of Kent Beck's new book
Test-Driven
> > Develoopment By Example:
> >
> >
http://groups.yahoo.com/group/testdrivendevelopment/files/TDD17Jul2002
> > .pdf
> >
>
> This is where I learned the most about TDD. And, I've implemented
unittests,
> but as I said in my previous post, I'm looking for test patterns
suiteable
> for database backed "objects".

There's a paper by Martin Fowler and Pramod Sadalage

http://www.martinfowler.com/articles/evodb.html

that just got posted recently on integrating relational data bases
into the XP development process.

> The .pdf referenced above does have some patterns, but I'm looking for
more
> ideas on database testing.. In my previous post I mentioned the "mock
> object" I used to capture SQL statements.. But that still doesn't test
the
> db dump/load aspect of my objects.

Refering to the paper above, you need to decouple the tests.
>
> I guess there's no getting around actually looking at the database
after
> storing an object..

There is, indeed, no substitute for having  a set of tests that verifies
that the schema is correct, and that whatever administration you need
to do is correct. That doesn't have to be unittest - whatever tools the
vendor supplies might be adequate as long as they can be automated
and will run silently.

>
> I'll probably use temporary tables and set them up in the fixture.
>
> Speaking of TestCase, I though that setUp would be called only once
for all
> test* included in the class, but I find that setUp() is called for
ever test
> case in the same class.

That's correct. The xUnit framework (of which unittest is an example)
has
that as a design goal - every test is independent. You can have a global
object, but you have to put it in yourself at the module level - see
either the
singleton pattern or the Borg pattern. Sometimes you have to, but it's a
good idea to spend time figuring out how not to do this.

> What I want is one instance of the TestCase to be created (hence, one
call
> to setUp()), then each test* case to be run in that TestCase instance.
>
> I guess I'll need to make up something to do it that way, since
setting up a
> temporary database table for every test in my suite will be expensive.

That's not the recommended way to do it. The recommended way is
to use a dual structure: mock objects for the bulk of your testing, and
then
a separate set of tests against the real data base, with an overnight
run with
real data base access to insure that the mock objects are doing the
right thing.

Otherwise you find that your unit test suite takes too long, and you
don't use it. As a rule of thumb, more than about two minutes for the
unit tests is too long.

John Roth