db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson" <...@bristowhill.com>
Subject Re: [JUnit] How CleanDatabaseTestSetup.decorateSQL works
Date Fri, 09 Feb 2007 00:26:06 GMT
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.
> 


Mime
View raw message