Oliver,
> -----Original Message-----
> From: Oliver Rossmueller [mailto:[EMAIL PROTECTED]]
> Sent: 26 August 2002 23:05
> To: Cactus Users List
> Subject: Re: JUnitEE and Cactus
>
> Vincent,
>
> let me say one statement upfront to make it clear: JUnitEE is not a
test
> framework for testing servlets/filters/taglibs.
> It is just a stupid
> little servlet that works as a JUnit TestRunner to execute JUnit test
> cases inside the J2EE-Container.
Ok. I understand (actually I did some time ago but I had forgotten it
seems :-)). Thus JUnitEE doesn't support testing of Servlets, Taglibs,
filter nor JSP. It only does EJB to some extent (by looking them up in
the container) and any java class not manipulating the servlet API.
Yes, it is purely a test runner ... So you can't test your EJBs,
servlet, JSP, taglib, filters by writing a test case in the following
format:
public void testXXX()
{
MyServlet servlet = new MyServlet();
servlet.init(config);
// test here
}
nor:
public void testXXX()
{
MyEJB ejb = new MyEJB();
Ejb.setSessionContext(context);
// test here
}
etc.
This is the JUnit way and is what I have been trying to do with Cactus.
In JUnitEE you have to look up the object and thus you can *only* call
the interface it exposes to the world : the doPost() (doGet(), etc)
method for a servlet). You would also have to open an http connection to
be able to do that ... and you wouldn't be able to unit test a method
like:
public void checkSession(HttpServletRequest req)
{
if (req.getSession(false) == null)
{
throw new ServletException("Session should have been created");
}
}
In the same spirit you can only test the exposed methods of EJBs.
Ok, I understand better now ...
[snip]
> >>- requires special test case super class
> >
> >
> > yep. Not sure this is really a problem though. Do you have an issue
in
> > mind ?
>
> It is an issue if we really decide to merge the two projects, because
> then it is a problem for the existing JUnitEE user base. Up to now
there
> was no need for a special superclass, so they would have to change all
> their tests to run them with Cactus.
>
Yes. JUnitEE's goal is to able to run in the container the **SAME** test
as you would run outside by using a standard junit test runner (apart
from the local EJBs).
> [cut]
>
> >>
> >>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?
>
> Yes and no. No, because this is not the target functionality of
JUnitEE
> which is just a test runner. Yes, because you can run whatever tests
you
> like and therefore also Cactus tests, for example.
Can you show me the code to unit test the following method:
public void checkSession(HttpServletRequest req)
{
if (req.getSession(false) == null)
{
throw new ServletException("Session should have been created");
}
}
That's an easy one (although complex to test with JUnitEE as you will
need to open an HTTP connection to the server itself). But a taglib
method would really be hard.
[snip]
> > 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).
>
> Competition is not a bad thing per se because it gives choice to the
> user. And the overlapping region of JUnitEE and Cactus is the Cactus
> servlet test runner, because this is close to what JUnitEE is doing.
And
> according Ant integration: Cactus does not need special Ant
integration
> - as I already mentioned in my previous mail - it just uses the JUnit
> task because client/server communication is hidden in the test case.
> JUnitEE requires a special Ant task doing no more than starting the
> tests in the container using the same URL you would enter in the
browser
> and to interpret the response from the servlet.
>
Ok. BTW, JUnitEE integration in Cactus already exists, there's even a
tutorial on the cactus web site.
However, I wanted to provide a servlet test runner to make it even
easier for users. It allows me to package it nicely inside Cactus.
However users have the choice: they can use JUnitEE or the Cactus
Servlet Test Runner.
[snip]
>
> That's a cool idea! If you have a servlet-only application I'm sure it
> works fine.
>
yeah, I'm still waiting for the EJB container that starts in 350 ms ...
:-)
>
> [cut]
>
> Perhaps I should tell a little bit about the applications I'm working
on
> and my requirements for a server-side test tool. Most of my
applications
> use a stupid front servlet that only does request dispatching and
hands
> over control to specific handler classes. These handlers then use EJBs
> or require database access, so the embedded Jetty is no help in my
case
> because I need a full-scale J2EE container as my test environment. I
do
> not unit test the front servlet because it is so simple and will be
> tested in integration and stress test. This makes testing the handler
> classes and the rest of the application easier because I have direct
> control of their input parameters without the indirection through the
> servlet, http request and all that stuff.
>
> So I don't need the servlet/filter/taglib testing features of Cactus,
I
> just need a way to get my tests executed inside the J2EE container.
> Well, I could do this with Cactus, but it is easier to do with
JUnitEE.
> I don't want to care about special test case classes -
> junit.framework.TestCase is good enough for my purpose - property
files
> and so on. Don't get me wrong, Cactus is a great tool, and I know what
> I'm talking about, because I used Cactus before I found JUnitEE.I just
> don't need it's features ...
Yes, you're correct for the moment ... In the next release, Cactus will
offer an EJB Redirector which I believe will be a compelling feature for
unit testing EJBs. Also some persons do not have any servlet front-end
at all (I'm working on such a project where our application is
message-driven and we use MDBs only) and using a servelt as a way inside
the system forces you to activate and set up a front end. The EJB
redirector will solve this issue.
>
> I think to get all the synergies out of our two projects you should
just
> bundle JUnitEE with Cactus and use it as your servlet test runner.
> That's exactly what JUnitEE is built for.
There is already an integration tutorial. I think you are right.
Bundling might be a good solution. I need to evaluate the features I
have in my servlet test runner and the ones in JUnitEE. ATM I can see
only one that I would be missing should I remove the Cactus servlet test
runner: it's the XML output. But you said you also wanted to put that in
JUnitEE ... :-)
>
> Well, we could make JUnitEE part of Cactus, but what would be the
> benefit? As I'm not interested in the other features of Cactus, you
> should not expect me to invest time in extending them. I would just
> extend the servlet test runner - see my previous mail for what I have
in
> mind - the same way I would extend JUnitEE. You can get the same by
just
> using JUnitEE as your test runner.
>
> I think there is place for both tools. JUnitEE is for all the people
who
> need just a simple server-side test runner and nothing more. I know
that
> there is at least one user - me of course ;-) And there is also a need
> for Cactus and it's features, otherwise you would not use and extend
it.
>
> If you think integrating JUnitEE makes sense for you and for Cactus
> anyway, let me know. I'm not completely against if, I just cannot see
> the benefit of that kind of action. And sorry, but you should not
expect
> to get too much help from my side for all the Cactus features you have
> in mind.
You are right. Let's keep the two projects separate and let's rather see
how we can improve and bundle junitee in Cactus as one additional test
runner (possibly removing the existing test runner once junitee does the
XML stuff).
Is that a plan ? :-)
Thanks for this interesting discussion.
-Vincent
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
