db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson" <...@bristowhill.com>
Subject [JUnit] How CleanDatabaseTestSetup.decorateSQL works
Date Thu, 08 Feb 2007 18:46:14 GMT
When I first starting working on the junit conversion for callable.java
(DERBY-2304) I had spotted the advice below in
http://wiki.apache.org/db-derby/KillDerbyTestHarness :

> How to execute DDL at setUp that is dropped automatically at tearDown?
> Provide a class that extends CleanDatabaseTestSetup and implement the decorateSQL method.
This can be achieved as an inner class, search for references to CleanDatabaseTestSetup for

To be honest, I had trouble understanding how decorateSQL worked. I did
get it working and thought I'd document my {mis}understanding here.
Maybe those who set up this junit test framework can correct and
clarify. If I can nail this info down, I'll then add it to the Wiki to
help the next person spinning up.

Given this goal:

A. Create SQL objects at the start of the test run
B. Reset those objects for each fixture
C. Drop SQL objects at the end of the test run

First of all, is this goal generally desirable? I think it is because
creating/dropping SQL objects for each fixture in a test probably won't
scale as we add more and more tests.

To satisfy this goal, the methods below need to be implemented (see
Dan's DERBY-2304 comment especially about automating B below [1]):

A. Create objects: code CleanDatabaseTestSetup.decorateSQL to do this
B. Reset objects: code setUp() to do this
C. Drop objects: you don't need to code anything --
CleanDatabaseTestSetup automagically does it for you.

The trickiest thing for me was understanding how to implement
CleanDatabaseTestSetup.decorateSQL, in part because I didn't see what
needed to be explicitly invoked and what would be automatically invoked
by the framework. I adopted the ProcedureTest.java approach and probably
my terminology isn't spot on for a description, but here is my
understanding of how it works:

1) The junit framework invokes the suite() method.

2) The suite() method should be coded to explicitly invoke addTest on
its own method that does whatever setup is needed -- ProcedureTest.java
calls this method baseSuite() and I did the same, but you can call it
anything you want because *you're* the one invoking it.

The suite() method is coded to explicitly call
suite.addTest(baseSuite()) twice: once for embedded and once for client.

Here's what the baseSuite() method does (should do?):

 a) creates the TestSuite
 b) adds the test's class to it, which will add all methods whose name
starts with "test"
 c) optionally adds any platform-specific tests. If you avoid prepending
"test" to the method name, step b won't automatically add it and you can
explicitly add it yourself.
 d) explicitly invokes a nested CleanDatabaseTestSetup, which creates
the decorateSQL method.
 e) The decorateSQL method creates the database objects

3) The junit framework invokes that decorateSQL method

Is this a good way to do it? or should anything change about it?

thanks in advance for corrections and clarifications,


[1] https://issues.apache.org/jira/browse/DERBY-2304#action_12471070

View raw message