On Thursday 10 April 2008 11:20:20 am Andrea Aime wrote:
> Gabriel Roldán ha scritto:
> > 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.
>
> Well, it looks a lot like my first attempt, and it fails because the
> same static variable is shared by all subclasses (so the one time
> initialization occurrs only once for the set of test classes you're
> running in the suite).
agreed, it is as hacky as it is. Yet doing it explicitly as a template class
(the final setUp and the setUp_Internal for subclass specific needs)
documents the "framework" far better than stating subclasses should call
super.setUp etc.
Honestly I'm a bit hesitant of switching to TestNG just because I'm lazy and
prefer to have a single unit testing framework across the projects we have to
deal with in parallel (that is geos/gt).
> We need a one time setup part that clears the the boolean flag before
> the test class starts, which is what I'm doing now... but feels
> quite a bit hacky.
What I don't quite understand is why having a oneTimeTearDown clearing the
flag wouldn't work? if not in the superclass itself, on the concrete
subclasses?
Gabriel
>
> I'm attaching my current solution (which uses TestData as a flag since
> I have to keep it around anyways). The issue I have with it is that
> it smells of a hack. With TestNG the hack would not be necessary, since
> the same test object is used to run all tests and the @BeforeClass
> annotated method does not need to be static.
>
> Oh, to use JUnit4 consistently we'd have to switch all the tests
> at once, since otherwise Eclipse (and I believe, Maven too) will
> notice our classes extend junit3 TestCase class and end up using
> junit3 runner instead of the junit4 one.
>
> The same would happen with TestNG. Which I do like more on a
> general point of view (the test approach seems quite a bit cleaner),
> but worries me when it comes to tool support maturity (see the maven
> issue).
>
> Cheers
> Andrea
>
>
> !DSPAM:4045,47fddbdf267478362916074!
-------------------------------------------------------------------------
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
