Hi Andrea,
good stuff.
I can only think of a custom "framework" to handle that, which would be
something like:
public abstract class GeoServerAbstractTestClass extends TestCase{
*private* static boolean oneTimeSetupDone = false;
public *final* void setUp() throws Exception{
if(!oneTimeSetupDone){
oneTimeSetup();
}
oneTimeSetupDone = true;
setUp_Internal();
}
/** oneTimeSetup not being static allows to use geos resources when already
available */
protected *abstract* void oneTimeSetup();
protected *abstract* void setUp_Internal()throws Exception;
}
This way, we call oneTimeSetup in a non static context, but let to the
concrete subclasses the responsability of writing their own oneTimeTearDown()
*static* method.
Let me know if that makes sense or what am I missing.
Cheers,
Gabriel
On Wednesday 09 April 2008 04:08:45 pm Andrea Aime wrote:
> Andrea Aime ha scritto:
> > Andrea Aime ha scritto:
> >> Hi,
> >
> > ...
> >
> >> Glub... any better idea?
> >
> > Hum, I managed to get it sort of working using only junit3. I realized
> > I could keep only the applicationContext and TestData fields
> > as static, and setup/teardown would stay non static, but access
> > the two static fields (which no subclass has legitimate needs
> > to override).
> > Basically, setup creates the static fields, and teardowns
> > decides whether to kill them or not based on a method
> > that provides a data/config modification flag.
> >
> > However, there is a big downside for this approach... since
> > the static field is the same (same base class), under surefire the same
> > data dir will be used for all tests (even of different classes).
> > Any idea of how to fix this???
>
> Sorry for this many mails, they are helping me think :)
> Ok, the fields could be wiped out by using a junit4 @BeforeClass
> method that nullifies them. This should work.
>
> It just feels quite a bit convoluted. The one time setup methods
> are not actually doing the one time setup, but only cleanup,
> whilst setup() internally does its checks and makes sure to
> reinitialize the data dir only when needed.
>
> Sure a TestNG solution would be cleaner... thought there
> seem to be some issues with it and surefire, in that one
> has to use the proper surefire/testng releases combo
> in order to have stuff work:
> http://www.kai-mai.com/node/96
>
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java
>one _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:4045,47fcce18114132090977483!
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
