tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "kelvin goodson" <kelvingood...@gmail.com>
Subject Re: [Java SDO CTS] Junit parameterized tests at odds with scope isolation
Date Mon, 30 Apr 2007 13:55:46 GMT
I have put in place  something along the lines of what I described above in
commit 533727 and have switched a couple of classes to using this new
approach.  I'm going to move all the parameterized tests in this direction
as I review them for inclusion in the adopted suite. Please speak up if you
think things should be different before I get too far along the way with
this change.

I also just moved ActiveUpdatingTest into the adopted suite.


On 27/04/07, kelvin goodson <kelvingoodson@gmail.com> wrote:
> After a small dig around I'm not sure how best to approach this slight
> conundrum.
> After putting in place some infrastructure to begin ensuring that we have
> a fresh type scope (HelperContext instance) per test case for the simple
> test case runs I turned my attention to a test class in the parameterized
> suite.  By experiment (as I couldn't lay my hands on the right
> documentation) it appears that the junit infrastructure creates MxN
> instances of the test data, where M is the number of test _classes_ and N is
> the number of data sets to run against the test classes.  It does this in a
> static method in advance of invoking any tests.
> I could change things so that we create a HelperContext per data set
> instance in the static method,  then use that HelperContext to create the
> rest of the SDO data for the test, and get all that injected by junit into
> the test classes instance.  But that only gives me a HelperContext per test
> class instance,  and that does not give the level of scope isolation we have
> learned that we would like, i.e. a fresh scope  per test _case_.
> One way to continue with the existing level of testing,  but to gain scope
> isolation, would be to get junit to inject factory instance into the test
> case, primed with an integer index. The factory method would create
> different test data sets according to the integer it is primed with. The
> setUp method could then call the factory to ask for test data.  This would
> give us the opportunity create a fresh HelperContext and create fresh
> instances of the test data using that helper context.
> Your thoughts and alternative solutions are welcome.
> Kelvin.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message