db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [JUnit] How CleanDatabaseTestSetup.decorateSQL works
Date Thu, 08 Feb 2007 20:04:13 GMT
Jean T. Anderson wrote:
> 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 examples.

>  d) explicitly invokes a nested CleanDatabaseTestSetup, which creates
> the decorateSQL method.
 >  e) The decorateSQL method creates the database objects

To tie the quote from the wiki and d) together I think d) & e) could be 
reworded, though I think you know what is going on.

d) decorate your test with an (instance of an) anonymous inner class 
that extends CleanDatabaseTestSetup and implements a decorateSQL method 
that creates the database objects and populates any tables as required.

Just that your version could imply that the decorateSQL method is 
created by running the suite method (it isn't, the compiler does that) 
and that it's run by the suite method (use of invoke).

Of course that may not be clearer than the original on the wiki. :-)

> 3) The junit framework invokes that decorateSQL method

Technically true (and maybe false as well :-), but I think somewhat 
misleading.

JUnit is Object Oriented, test runners only knows about Tests, they just 
runs Tests, ie perform the "run action" of that Test. However, the test 
runners know nothing of what happens when these are run, they just make 
sure that the Test is run. This is one of the beauties of JUnit.

There are different types of Tests, the three typically used in Derby 
are fixtures, suites and decorators.

A fixture is an instance of a class and a public void method in that 
class. Its run action is to:
       1) call setUp() method
       2) call fixture method (e.g. testInsertStatement())
       3) call tearDown() method

A suite is just a list of other Tests (not just fixtures, but any type 
of Test). Its run action is to:
      1) for each Test in its list: perform the run action of that Test.

A decorator is an instance of a class and another Test (again any type 
of Test). Its run action is to:
       1) call its (the decorator's) setUp method
       2) perform the run action of its Test
       3) call its (the decorator's) tearDown method

(I guess it decorates the Test by adding "frills" around it?)

So to look at CleanDatabaseTestSetup we can see from its javadoc that 
its specific run action is:
   1a) clean the database
   1b) call decorateSQL (which does nothing)
   1c) call commit
   2) perform the run action of its Test
   3) clean the database

Now if I have an anonymous inner class that extends 
CleanDatabaseTestSetup and provides a decorateSQL method then its run 
action is:
   1a) clean the database
   1b) call decorateSQL which creates the required database state.
   1c) call commit
   2) perform the run action of its Test
   3) clean the database

So technically it is not JUnit that is calling decorateSQL, but instead 
CleanDatabaseTestSetup which is a decorator and thus just a Test.

HTH,
Dan.


Mime
View raw message