jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: JUnitEE and Cactus
Date Mon, 26 Aug 2002 10:14:47 GMT
Hi Oliver,

> -----Original Message-----
> From: Oliver Rossmueller [mailto:oliver@oross.net]
> Sent: 25 August 2002 15:50
> To: Vincent Massol
> Subject: JUnitEE and Cactus
> Hi Vincent,
> finally I could find some time to check out the latest release of
> Cactus, so here are from my point of view the advantages and
> disadvantages of JUnitEE and Cactus:
> Advantages of JUnitEE
> - no special requirements to test case classes -
> junit.framework.TestCase as superclass is enough

ok. The only reason for having to extend a given test class (on the
server side) is to easily pass the servlet objects (request, response,
etc) to the test. How is this done by JUnitEE? By calling some static
class? The TestCase could also be wrapped but then the user will have to
perform a cast to access the additional features.

> - as simple as possible: write your tests, package them in a WAR with
> JUnit and JUnitEE, deploy the WAR and start your tests from your

Actually this is also exactly the lifecycle with Cactus if you want to
test from your browser. If you want to test with your IDE, Ant, etc,
simply use *any* existing test runner (including JUnitEE ! :-))and off
you go.

> Disadvantages of JUnitEE
> - requires special Ant task which does the client/server communication

Does JUnitEE already provides this? It didn't last time I looked. If it
now does, then Cactus and JUnitEE are now really the same, as this is
what is done in Cactus :-). Another reason to merge ... :)

> Advantages of Cactus
> - no special Ant integration is necessary as the junit task will also
> run Cactus test cases (the client/server communication is encapsulated
> in the test case itself)


> - testing of servlet output is easy because of httpunit integration


> Disadvantages of Cactus
> - configuration of client-side cactus.properties

yes and no. cactus.properties is optional. However, you still need to
tell Cactus what URL it should call to find its redirector (that's the
only piece of information that is required). Note that this is not
needed if you're running your test from a browser.

> - requires special test case super class

yep. Not sure this is really a problem though. Do you have an issue in
mind ?

> - servlet test runner produces xml which is displayed in a useful
> in IE only; for other browsers a transformation to html would be
> required but would also require xerces/xalan in the WAR

yes, you're right. I would be +1 to offer an HTMLFormatter class in
addition to the XMLFormatter one that exist for users who do not use a
browser that can display XML *and* that cannot do XSLT transformation.
That's one of the things JUnitEE could bring should we agree to merge
... :-)

> I was thinking about how to integrate the two projects. The most
> important aspect of JUnitEE is it's simplicity and ability to run test
> cases of any kind inside the servlet container. 

Can you write taglib tests with JUnitEE? Can you write Filter tests too?

> To get the same out of
> Cactus would mean to remove client/server communication from the test
> case. 

Not true :-) Cactus already provides this. The tomcat integration
tutorial (http://jakarta.apache.org/cactus/howto_tomcat.html) shows that
you don't have to care about the client/server communication at all.

> This is a big change of Cactus' architecture and would require a
> complete rework and would probably break existing Cactus-based test
> cases. So I don't think you would like to go this way.

I don't understand. Can you please give me more details?

> The only realistic way in cooperation that would make sense for me is
> for you to use JUnitEE as the servlet test runner instead of writing
> your own one. So you could benefit from the development of JUnitEE and
> concentrate on the core features of Cactus. For example I could extend
> JUnitEE to produce xml output as your test runner does. I was already
> thinking about using xml for the communication with the ant task, so I
> might do it anyway.

Ok. Here is my point of view:

- I think this niche of in-container unit testing is too small for
having 2 projects
- You mentioned an Ant taks for JUnitEE to communicate with the server
side. This is exactly the same as Cactus. This means that JUnitEE and
Cactus become competitors (they are on the same domain).
- I believe it is *way* better to join our forces and make something
better for our users than each separate project. You are working alone
on JUnitEE and I am working almost alone on Cactus. Let's join forces!
There are still lots of things to do to improve integration unit testing
   - EJB redirectors including MDB redirector for unit testing MDBs
   - Bundling Cactus/JUnitEE with application server containers to make
them a de facto standard.
   - Write IDE plugins to make it even easier. I have started a Maven
plugin for Cactus and I am currently learning plugin development in
Eclipse in order to write a Cactus plugin

> You mentioned  some plugins you would like to create for Cactus. Could
> you be a little bit more specific in this point and also in what your
> plans for Cactus are? 

See above. You can also get some ideas by looking at the todo list :

In addition, there may be another new area of testing that could be
interesting (that's for more longer term) : "Stress Unit Testing" (TM)

Persons who write server side applications are usually writing them to
support heavy loads and would be very interested to know how some
specific methods handle the load (and test thread handling). Ok, there
are lots of issues to discuss and I'm not even sure it could work but
that's an idea.

Moreover there are persons who have started extensions to Cactus for
providing even further ease of testing for specific frameworks. An
example is the StrutsTestCase project for unit testing Struts actions.

I am also currently integration Jetty completely into Cactus as a Cactus
extension. You may know that Jetty is a very fast embeddable servlet
engine. It is working on my machine (I haven't committed it yet) and the
net result is that I can now start servlet/filter/JSP tests without
having to create a WAR and deploying it! Ok, it won't fit all scenarios
but it is a *very* fast way to unit test your code in a container! Jetty
starts in 350 ms ! Here is how you can use it:

    jetty jar

  my tests

That's the minimum you need! Nothing more, no config files, etc. 

I would view this method as very useful when you're inside your IDE and
writing your code. As soon as you have finished one method, you right
click on your test and use the IDE JUnit integration and click "run" and
it starts in 350 ms and run your test. Wow! Then as a second step you
would automate running the tests in Ant for example using your real
container, and you would run these tests less often (for example every
few hours or once very day).

> I have also some points on my list for the next
> release of JUnitEE:
> - allow to run a single test out of a test suite; this is very helpful
> for debugging and is the most important feature I'm missing in JUnitEE
> at the moment

yes. Good idea :-)

> - create a servlet/jsp which displays all test suites and tests
> available so you can select the suites and tests you would like to run
> in the browser in a user-friendly way

another good idea ...

> - flush mode of the test runner so you get immediate feedback while
> tests are running and don't have to wait until all tests are finished
> see the results

yes that would be nice ...

> That's it for the moment. Perhaps when I know more about your plans
> ideas we will find other possibilities to cooperate, at the moment I
> only see the way mentioned above.

Oliver, I really think we should merge and bring all these wonderful
ideas together.

Tell me what you think


> Greetings
> Oliver
> Vincent Massol wrote:
> >Hi Oliver,
> >
> >Good to see that someone as taken the lead on JUnitEE! I am working
> >Cactus and in version 1.4, Cactus has added a ServletTestRunner in
> >addition to supporting all the existing JUnit Test Runner.
> >
> >I have to say that although Cactus has a strong community of users, I
> >the only person really leading the Cactus project and I'm really
> >for synergies/help/partners/etc.
> >
> >I think Cactus and JunitEE are doing very very similar things now and
> >that Cactus is now as easy to use as JUnitEE (If not, that's one
> >we could work on! :-)). I would be very happy to integrate any
> >feature that you would like to bring ... ;-)
> >
> >I think, this domain of integration unit testing is very small and we
> >could benefit from mutual help. There are still nice things to do ...
> >like the EJB Redirector stuff ...
> >
> >Would you be open to discuss this ?
> >
> >Thanks a lot
> >-Vincent
> >
> >
> >
> >>-----Original Message-----
> >>From: junitee-user-admin@lists.sourceforge.net [mailto:junitee-user-
> >>admin@lists.sourceforge.net] On Behalf Of Oliver Rossmueller
> >>Sent: 15 August 2002 21:59
> >>To: junitee-user@lists.sourceforge.net
> >>Subject: [junitee-user] Release 1.4
> >>
> >>Release 1.4 of JUnitEE is available for download at
> >>http://sourceforge.net/project/showfiles.php?group_id=31476
> >>
> >>Changes:
> >>------------
> >>- New option to run all tests found in a specified jar file
> >>- Ant task for build integration
> >>- TestServletBase is no longer abstract and should work as is
> >>- Bug Fixes (Bug 583856, 583859)
> >>
> >>
> >
> >
> >
> >

To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>

View raw message