RE: [mevenide-user] Advice on test design

 Andy,

> -----Original Message-----
> From: andy law (RI) [mailto:[email protected]] 
> Sent: Tuesday, November 27, 2007 11:05 AM
> To: [email protected]
> Subject: RE: [mevenide-user] Advice on test design
> 
> Daniel,
> 
> > 
> > Your testcode should be responsible for loading the property 
> > file to use for configuration your app
> > 
> > therefore you can call your app by passing a purpose 
> > configuration file for each test....
> > 
> > the default property file can be located in the jar 
> > /src/main/resources (this will go in the jar)
> > 
> > the testfiles can be located in
> > /src/test/resources (this will go in the test-jar) or any 
> > other folder below src/test then you can see the files in 
> > 'Other Test Sources' (this is how it works in NB6.0)
> > 
> > as Emilian also mentioned is always easier to use 
> > InputStreams for loading resources.
> > 
> > this.getClass().getRessourceAsStream().... or something like that
> > 
> 
> 
> Yeah, but... :o}
> 
> The code I'm writing is a struts 2 interceptor. Its called 
> from inside a
> framework so it doesn't have scope for a set/get of the configuration.
> It *has* to be stand-alone, so it *has* to read its own configuration
> (or am I misunderstanding what you are both suggesting?)
> 
> We already do the test/default properties file dance with
> src/(main|test)/resources with other code that we write. In particular
> we use that route for configuring developer-specific database
> connections for testing versus application-specific connections for
> deployment.
> 
> I think I need to revisit the spec on this to see if we can't shake
> something more tractable out of it.
> 

I'm not a web developer, therefore I don't know how to est things in 
this context but....

I just had a look here:
http://struts.apache.org/2.0.11/docs/writing-interceptors.html

and therefore there is not a lot to do about it.

For testing I would just implement one more method on the interface to
set the current config file. the init method would then use the default
or the
new file if the file is valid...

for testing you can instantiate the Interceptor in the test code outside
of
the struts context and set the appropriate testfile and maybe you can
also validate
the initialisation when you call the intercept method directly....

Maybe this is a way to test the Interceptor out of scope, if this is
possible..

I'm not a web developer so this is only an idea.

 
> > Happy testing
> 
> 
> Testing is *always* happy, isn't it?
> 
> 
> > 
> > Daniel
> > 
> > PS: JUnit 4.x makes testing so much easier...
> 
> 
> Would it help with the above - and does it all 'just work' 
> with Netbeans
> 5.5/mevenide?

I have no Idea, as I switched to NB6 in August, I think the junit
module is not uptodate in nb5.5 but this may be wrong..

Daniel


> 
> Later,
> 
> Andy
> 
> -------------
> Yada, yada, yada...
> 
> Roslin Institute is a company limited by guarantee, registered in
> Scotland (registered number SC157100) and a Scottish Charity 
> (registered
> number SC023592). Our registered office is at Roslin, Midlothian, EH25
> 9PS. VAT registration number 847380013.
> 
> The information contained in this e-mail (including any 
> attachments) is
> confidential and is intended for the use of the addressee only.   The
> opinions expressed within this e-mail (including any attachments) are
> the opinions of the sender and do not necessarily constitute those of
> Roslin Institute (Edinburgh) ("the Institute") unless specifically
> stated by a sender who is duly authorised to do so on behalf of the
> Institute.
>  
> 
> 
> >   
> > > -----Original Message-----
> > > From: Emilian Bold [mailto:[email protected]]
> > > Sent: Tuesday, November 27, 2007 10:32 AM
> > > To: [email protected]
> > > Subject: Re: [mevenide-user] Advice on test design
> > > 
> > > If you expect to have the properties file in a JAR then indeed it 
> > > doesn't seem to work. But you might use an actual File to get the 
> > > property and then you either have it in /tmp for example of not.
> > > 
> > > Another, nicer, way would be to allow your class to use 
> > InputStreams.
> > > This way you can have a valid property with the inputstream 
> > > (getClass().getResource("valid.pro")), an invalid one, and 
> > a missing 
> > > (null stream) one.
> > > 
> > > My 2c,
> > > Emilian
> > > 
> > > On Nov 27, 2007 11:28 AM, andy law (RI) 
> <[email protected]> 
> > > wrote:
> > > > All,
> > > >
> > > > I *know* this is mostly off-topic for this list (and I 
> > apologise in 
> > > > advance), but I figure this is still a good place to start.
> > > >
> > > > I am running Netbeans 5.5 with mevenide trying to decide
> > > how I attack
> > > > the following problem:
> > > >
> > > > Let's assume that I'm writing some code that uses a
> > > properties file to
> > > > define some parameter or other. In the absence of the
> > > properties file,
> > > > the code should use a sensible default value. So, I have
> > > the following
> > > > tests to run
> > > >
> > > > 1) No properties file - default behaviour
> > > > 2) Properties file with nonsense value - default behaviour
> > > with warning
> > > > 3) Properties file with sensible value - use supplied value
> > > >
> > > > How do I run tests 1 *and* 2/3 in the same project given
> > > that the test
> > > > properties file is either supplied or not (as far as I 
> > can tell) in 
> > > > src/test/resources.
> > > >
> > > > Later,
> > > >
> > > > Andy
> > > >
> > > > -------------
> > > > Yada, yada, yada...
> > > >
> > > > Roslin Institute is a company limited by guarantee, 
> registered in 
> > > > Scotland (registered number SC157100) and a Scottish
> > > Charity (registered
> > > > number SC023592). Our registered office is at Roslin,
> > > Midlothian, EH25
> > > > 9PS. VAT registration number 847380013.
> > > >
> > > > The information contained in this e-mail (including any
> > > attachments) is
> > > > confidential and is intended for the use of the addressee
> > > only.   The
> > > > opinions expressed within this e-mail (including any
> > > attachments) are
> > > > the opinions of the sender and do not necessarily
> > > constitute those of
> > > > Roslin Institute (Edinburgh) ("the Institute") unless 
> > specifically 
> > > > stated by a sender who is duly authorised to do so on 
> > behalf of the 
> > > > Institute.
> > > >
> > > >
> > > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > > To unsubscribe from this list please visit:
> > > >
> > > >     http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > > 
> > > 
> > > 
> > > --
> > > Emilian Bold
> > > +40 740235562
> > > http://www.emilianbold.ro
> > > 
> > > Java and NetBeans Platform-loving consulting services from 
> > Timisoara, 
> > > Romania.
> > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > > 
> > >     http://xircles.codehaus.org/manage_email
> > > 
> > > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> > 
> >     http://xircles.codehaus.org/manage_email
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
> 
>     http://xircles.codehaus.org/manage_email
> 
> 

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email