thanks for the excellent feedback, Dan. I'll summarize on the wiki in just over a week (will be at a conference tomorrow then out next week but with some email access). So anyone feel free to add more wisdom, clarifications, etc. and I'll consolidate it all when I get back.
-jean Daniel John Debrunner wrote: > 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. >
