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.
