PSP, XP, TDD and other methodologies for solitary programmers
johnroth at ameritech.net
Fri Jan 3 15:23:20 CET 2003
"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
> > Develoopment By Example:
> > .pdf
> This is where I learned the most about TDD. And, I've implemented
> but as I said in my previous post, I'm looking for test patterns
> for database backed "objects".
There's a paper by Martin Fowler and Pramod Sadalage
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
> 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
> 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
> 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
> test* included in the class, but I find that setUp() is called for
> case in the same class.
That's correct. The xUnit framework (of which unittest is an example)
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
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
> 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
a separate set of tests against the real data base, with an overnight
real data base access to insure that the mock objects are doing the
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.
More information about the Python-list