Re: Contacting the container from beginXXX()
DBUnit looks nice but how would you integrate with it Cactus? Each one requires you to extend a different class and Java doesn't do multiple inheritance. Gili Korver, Aaron wrote: [snip] Why don't you simply fill the database with the right values? No need for any hibernate mapping for this! It can be done in several ways, with a SQL script, by saving a database dump and reloading it, etc. [snip] May I also suggest using dbunit[1]? We have been using this successfully in our environment to setup a fixture and restore a DB to a known state. If you use it with an in-memory DB you can get pretty good performance. You just want to only do these tests nightly. Then mock out your DB and run the "logic" tests using mocks. Remember that developers are lazy, so if your tests take to long to run, then no one will use them. [1] www.dbunit.org Aaron Korver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Contacting the container from beginXXX()
[snip] > Why don't you simply fill the database with the right values? > No need for > any hibernate mapping for this! It can be done in several > ways, with a SQL > script, by saving a database dump and reloading it, etc. [snip] May I also suggest using dbunit[1]? We have been using this successfully in our environment to setup a fixture and restore a DB to a known state. If you use it with an in-memory DB you can get pretty good performance. You just want to only do these tests nightly. Then mock out your DB and run the "logic" tests using mocks. Remember that developers are lazy, so if your tests take to long to run, then no one will use them. [1] www.dbunit.org Aaron Korver
RE: Contacting the container from beginXXX()
> -Original Message-
> From: Gili [mailto:[EMAIL PROTECTED]
> Sent: samedi 7 mai 2005 16:50
> To: Cactus Users List
> Subject: Re: Contacting the container from beginXXX()
>
> Vincent Massol wrote:
> > Gili,
> >
> > It's important to choose the right type of test for the job so that the
> test
> > is as easy as possible to write/maintain.
> >
> > Here are some ideas:
> >
> > * It seems strange that you don't control the data in the database. For
> > testing it's a good idea to control what you put in the database. If you
> do
> > then you know exactly what's in there and you shouldn't need to call the
> > database to get test input data from it.
>
> Right, I might go in this direction but it requires me to use two
> different Hibernate mapping files: one for production builds (IDs are
> generated automatically) and one for test builds (IDs are provided by
> the developer). It just makes things a bit more complicated.
Why don't you simply fill the database with the right values? No need for
any hibernate mapping for this! It can be done in several ways, with a SQL
script, by saving a database dump and reloading it, etc.
> > * Calling the database to get a fixture seems too complex to me and it
> seems
> > what you really want to do is a functional test (not an integration or
> unit
> > test). How are you running your functional tests? Why don't you add this
> > test to your suite of functional tests?
>
> I don't know what one uses for functional tests (and how these
> differ
> from unit tests). I was under the impression that Cactus could be used
> for this.
It depends on your front end. If it's web then use tools like
HtmlUnit/HttpUnit, etc. If it's swing you could use Abbot, etc.
Cactus does integration (unit) tests.
> > * If you really need to perform a unit test, I would suggest that you
> don't
> > hit the database at all, using a MockObjects/Stub approach instead (pure
> > JUnit without Cactus). That will allow you to test the code logic in
> unit
> > tests. Then you couple this with a functional test and you should get a
> > pretty good coverage
>
> I don't think there is an easy way to stub out the Hibernate
> objects.
> Sounds like way too much work for too little gain.
It's only hard work if you have a bad design and you need to refactor it...
That's the main gain of true unit tests: they improve your code design.
I'd advise checking a book on the topic (say, for example, JUnit in Action
;-)).
> > All that said, if you still want to use Cactus you should be able to
> write
> > the following in your beginXXX() method:
> >
> > String serverURL = System.getProperty("cactus.contextURL");
>
> I suspect (but please let me know) that the webapp to be tested is
> not
> deployed by the time beginXXX() is called and it is only deployed before
> testXXX().
If you're using the Maven plugin or the Ant task, you can be sure
that the cactified webapp is already deployed.
> I already tried hitting localhost:8080 (which is my test
> server address) and got an HTTP which I think was due to a webapp not
> deployed error.
It was probably something else.
> If you can think of an easier way than using different Hibernate
> mapping files and generating IDs manually, please let me know :)
Yes, fill the database with known values whether it's from a SQL script,
whether it's from a TestSetup method, etc. Don't fill the whole database,
just what is needed for the test.
-Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Contacting the container from beginXXX()
> -Original Message-
> From: Gili [mailto:[EMAIL PROTECTED]
> Sent: samedi 7 mai 2005 16:50
> To: Cactus Users List
> Subject: Re: Contacting the container from beginXXX()
>
> Vincent Massol wrote:
> > Gili,
> >
> > It's important to choose the right type of test for the job so that the
> test
> > is as easy as possible to write/maintain.
> >
> > Here are some ideas:
> >
> > * It seems strange that you don't control the data in the database. For
> > testing it's a good idea to control what you put in the database. If you
> do
> > then you know exactly what's in there and you shouldn't need to call the
> > database to get test input data from it.
>
> Right, I might go in this direction but it requires me to use two
> different Hibernate mapping files: one for production builds (IDs are
> generated automatically) and one for test builds (IDs are provided by
> the developer). It just makes things a bit more complicated.
Why don't you simply fill the database with the right values? No need for
any hibernate mapping for this! It can be done in several ways, with a SQL
script, by saving a database dump and reloading it, etc.
> > * Calling the database to get a fixture seems too complex to me and it
> seems
> > what you really want to do is a functional test (not an integration or
> unit
> > test). How are you running your functional tests? Why don't you add this
> > test to your suite of functional tests?
>
> I don't know what one uses for functional tests (and how these
> differ
> from unit tests). I was under the impression that Cactus could be used
> for this.
It depends on your front end. If it's web then use tools like
HtmlUnit/HttpUnit, etc. If it's swing you could use Abbot, etc.
Cactus does integration (unit) tests.
> > * If you really need to perform a unit test, I would suggest that you
> don't
> > hit the database at all, using a MockObjects/Stub approach instead (pure
> > JUnit without Cactus). That will allow you to test the code logic in
> unit
> > tests. Then you couple this with a functional test and you should get a
> > pretty good coverage
>
> I don't think there is an easy way to stub out the Hibernate
> objects.
> Sounds like way too much work for too little gain.
It's only hard work if you have a bad design and you need to refactor it...
That's the main gain of true unit tests: they improve your code design.
I'd advise checking a book on the topic (say, for example, JUnit in Action
;-)).
> > All that said, if you still want to use Cactus you should be able to
> write
> > the following in your beginXXX() method:
> >
> > String serverURL = System.getProperty("cactus.contextURL");
>
> I suspect (but please let me know) that the webapp to be tested is
> not
> deployed by the time beginXXX() is called and it is only deployed before
> testXXX().
If you're using the Maven plugin or the Ant task, you can be sure
that the cactified webapp is already deployed.
> I already tried hitting localhost:8080 (which is my test
> server address) and got an HTTP which I think was due to a webapp not
> deployed error.
It was probably something else.
> If you can think of an easier way than using different Hibernate
> mapping files and generating IDs manually, please let me know :)
Yes, fill the database with known values whether it's from a SQL script,
whether it's from a TestSetup method, etc. Don't fill the whole database,
just what is needed for the test.
-Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contacting the container from beginXXX()
Vincent Massol wrote:
Gili,
It's important to choose the right type of test for the job so that the test
is as easy as possible to write/maintain.
Here are some ideas:
* It seems strange that you don't control the data in the database. For
testing it's a good idea to control what you put in the database. If you do
then you know exactly what's in there and you shouldn't need to call the
database to get test input data from it.
Right, I might go in this direction but it requires me to use two
different Hibernate mapping files: one for production builds (IDs are
generated automatically) and one for test builds (IDs are provided by
the developer). It just makes things a bit more complicated.
* Calling the database to get a fixture seems too complex to me and it seems
what you really want to do is a functional test (not an integration or unit
test). How are you running your functional tests? Why don't you add this
test to your suite of functional tests?
I don't know what one uses for functional tests (and how these differ
from unit tests). I was under the impression that Cactus could be used
for this.
* If you really need to perform a unit test, I would suggest that you don't
hit the database at all, using a MockObjects/Stub approach instead (pure
JUnit without Cactus). That will allow you to test the code logic in unit
tests. Then you couple this with a functional test and you should get a
pretty good coverage
I don't think there is an easy way to stub out the Hibernate objects.
Sounds like way too much work for too little gain.
All that said, if you still want to use Cactus you should be able to write
the following in your beginXXX() method:
String serverURL = System.getProperty("cactus.contextURL");
I suspect (but please let me know) that the webapp to be tested is not
deployed by the time beginXXX() is called and it is only deployed before
testXXX(). I already tried hitting localhost:8080 (which is my test
server address) and got an HTTP which I think was due to a webapp not
deployed error.
If you can think of an easier way than using different Hibernate
mapping files and generating IDs manually, please let me know :)
Thank you,
Gili
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Contacting the container from beginXXX()
Gili,
It's important to choose the right type of test for the job so that the test
is as easy as possible to write/maintain.
Here are some ideas:
* It seems strange that you don't control the data in the database. For
testing it's a good idea to control what you put in the database. If you do
then you know exactly what's in there and you shouldn't need to call the
database to get test input data from it.
* Calling the database to get a fixture seems too complex to me and it seems
what you really want to do is a functional test (not an integration or unit
test). How are you running your functional tests? Why don't you add this
test to your suite of functional tests?
* If you really need to perform a unit test, I would suggest that you don't
hit the database at all, using a MockObjects/Stub approach instead (pure
JUnit without Cactus). That will allow you to test the code logic in unit
tests. Then you couple this with a functional test and you should get a
pretty good coverage
All that said, if you still want to use Cactus you should be able to write
the following in your beginXXX() method:
String serverURL = System.getProperty("cactus.contextURL");
-Vincent
> -Original Message-
> From: Gili [mailto:[EMAIL PROTECTED]
> Sent: vendredi 6 mai 2005 21:46
> To: Cactus Users List
> Subject: Re: Contacting the container from beginXXX()
>
>
> Correct. I have a DB on the server end containing a list of Themes.
> Each theme contains a list of Images. I need to simulate what happens by
> picking a random theme and image and hitting the servlet with it.
>
> Alternatively, I was going to try to move this logic into the
> testXXX()
> method and do everything on the server side, but that would require me
> to implement HttpServletRequest and control what request/response each
> call gets and anyway, as you well know, it gets out of control very
> quickly.
>
> There is no way for me to guess a valid value ahead of time because
> the
> themes, images are referenced by ID which is automatically generated by
> the underlying DB and these change whenever a row is added or removed.
> Before each test, I regenerate the DB data and this causes the
> underlying IDs to change.
>
> Any suggestions on what I can do?
>
> Gili
>
> Vincent Massol wrote:
> > Hi Gili,
> >
> > Are you sure you need to contact the server? Why can't you guess a valid
> > value?
> >
> > Is that the real use case? I mean does your client application have to
> call
> > the server side before it can call your business method?
> >
> > -Vincent
> >
> >
> >>-Original Message-
> >>From: Gili [mailto:[EMAIL PROTECTED]
> >>Sent: vendredi 6 mai 2005 19:28
> >>To: cactus-user@jakarta.apache.org
> >>Subject: Contacting the container from beginXXX()
> >>
> >>Hi,
> >>
> >> I need to be able to contact the container from within my
> >>beginXXX() method because that method needs to invoke a servlet to
> >>retrieve information which will get stuffed into the WebRequest object.
> >>Is there a way to get the test server URL from within beginXXX()?
> >>
> >>Thanks,
> >>Gili
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contacting the container from beginXXX()
Correct. I have a DB on the server end containing a list of Themes. Each theme contains a list of Images. I need to simulate what happens by picking a random theme and image and hitting the servlet with it. Alternatively, I was going to try to move this logic into the testXXX() method and do everything on the server side, but that would require me to implement HttpServletRequest and control what request/response each call gets and anyway, as you well know, it gets out of control very quickly. There is no way for me to guess a valid value ahead of time because the themes, images are referenced by ID which is automatically generated by the underlying DB and these change whenever a row is added or removed. Before each test, I regenerate the DB data and this causes the underlying IDs to change. Any suggestions on what I can do? Gili Vincent Massol wrote: Hi Gili, Are you sure you need to contact the server? Why can't you guess a valid value? Is that the real use case? I mean does your client application have to call the server side before it can call your business method? -Vincent -Original Message- From: Gili [mailto:[EMAIL PROTECTED] Sent: vendredi 6 mai 2005 19:28 To: cactus-user@jakarta.apache.org Subject: Contacting the container from beginXXX() Hi, I need to be able to contact the container from within my beginXXX() method because that method needs to invoke a servlet to retrieve information which will get stuffed into the WebRequest object. Is there a way to get the test server URL from within beginXXX()? Thanks, Gili - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Contacting the container from beginXXX()
Hi Gili, Are you sure you need to contact the server? Why can't you guess a valid value? Is that the real use case? I mean does your client application have to call the server side before it can call your business method? -Vincent > -Original Message- > From: Gili [mailto:[EMAIL PROTECTED] > Sent: vendredi 6 mai 2005 19:28 > To: cactus-user@jakarta.apache.org > Subject: Contacting the container from beginXXX() > > Hi, > > I need to be able to contact the container from within my > beginXXX() method because that method needs to invoke a servlet to > retrieve information which will get stuffed into the WebRequest object. > Is there a way to get the test server URL from within beginXXX()? > > Thanks, > Gili - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
