> -----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 <cactus> 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]
