----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 30, 2001 10:22 AM
Subject: RE: html interface for Cactus (JUnitEE)
> > Thanks Kaarle for your enthousiasm ! :)
> >
> > Yes, I remember when I first found JUnitEE about 8 months
> > ago, we discussed with Jeff Schnitzer about the merit of
> > his servlet side test runner. The problem I had (and I
> > still have), please correct me if I'm wrong, is that it
> > is a manual process to check if the test has succeeded or
> > not. That is, you open your browser, call the url for
> > running the tests (the servlet runner), execute the
> > tests and view the results as a returned HTML page.
> > There are several issues with this :
> >
>
> hi Vincent!
>
> I suppose it is a manual process. I have looked a bit into Ant
> but I cannot say that I would be very familiar with it yet.
> I had some classpath problems with some commands in Ant that
> did not function correctly in weblogic 5.1 environment.
> Perhaps in weblogoc 6.x and I suppose systems like orion, tomcat
> and such may not have these problems.
I have used Ant and WL since version 5.1 (even 4.5) and it works very well.
You may be refering to issues using the ejbc task or such. These are simply
convenience tasks and you do not need to use them. Simply use the java task.
>
> All tests I have made I have thus only verified manually
> both using the swingui and JUnitEE.
read http://www.martinfowler.com/articles/ciWithCom.html ...
>
> > A- This may be fine for development but when you arrive at
> > the stage where you want to automate your build process,
> > send an email when the build fails (for example, upon
> > running a test that fails), it is no longer providing a
> > good solution. B- Your cannot integrate with existing
> > tool as they are running either the default test runner
> > or one of the gui one. All JUnit plugins for ides for
> > example will run fine with Cactus because Cactus is
> > test-runner-neutral.
> > C- You cannot pass, in a reproductible manner, HTTP
> > parameters to your test (like HTTP parameters,
> > cookies, HTTP headers, simulate a URL, ...). In other
> > words, it is as if your Cactus test case did not have a
> > beginXXX() method.
> > D- You cannot assert the results of a returned requests (like
> > check for HTTP response code, cookies, content,..). Everything
> > that is in the endXXX() method.
> > E- JUnitEE is not marketed to be a new test runner for JUnit
> > but rather an extension to provide server side unit testing
> > (same as Cactus). So persons will not think about JUnitEE
> > as a front end for Cactus right away.
> >
> > That said, let's look at some solutions ... :)
> > -A/B are really a problem because there is no easy way to get that.
>
> I agree that this can probably not be done with JunitEE as GUI.
> But for this kinds you have all the other TestRunners.
> I did not really propose that JUnitEE should replace anything
> of the existing ones, but to be an additional interface
> to be used where it is suitable.
>
ok. then we agree to view junitee simply as another test runner.
> > -C/D could be solved if the servlet test runner opens an HTTP
> > connection to the same server
>
> If I understand correctly I already solved this. The environment
> where I tested this contained about the following components.
>
> - junit.jar, cactus.jar and junitee.jar in the classpath
> (of weblogic 5.1)
> - cactus.properties in the classpath
> - redirector.jsp as defined in cactus.properties
> - TestServlet.class in classpath (i.e. JUnitEE) where the
> User Interface (a jsp or html page) can find it.
> Whatever is needed that TestServlet.class is recognized as a servlet
> such as weblogic.httpd.register.TestServlet=com.tests.TestServlet
> in weblogic.properties - file
>
> I think what happens here is
> 1) User presses submit (or link) on webpage
> 2) TestServlet is called. In case the tescase extend
> 2a) junit.framework.TestCase it is executed directly and if it extends
> 2b) org.apache.cactus.JspTestCase it uses the Cactus mechanism
> redirect.jsp -> cactus.jar - junit.jar ??
>
> In both cases all tests are executed in the server environmnet
> which at least in some cases is an advantage.
it simply means the client part of Cactus is executed on the server. The
difference is that you are now running the client and server parts of Cactus
in the same JVM so you must put everything in your war classpath :
- add the httpclient jar to web-inf/lib
- (optional) add the httpunit and dependent jars to web-inf/lib
- add cactus.properties to web-inf/classes
it is maybe slighlty easier to set up for a new comer that doesn't
understand how it works but is a bit more complex to understand and is not
very logical (you are not expecting to find the client side part in the
server !).
>
> > -E is not really an issue. I think I remember I saw some time
> > in the past a junit test runner extension which was a sevlet but am not
> > sure anymore. It may already exist and would work with Cactus (as almost
> any
> > test runner would, as a cactus test case is a junit test case).
> >
>
> I don't think this is an issue either. But as Cactus is the more visible
> project and JUnitEE could be considered another UI also for Cactus
> this issue could change if it would be visible also on Cactus pages.
>
> > I agree with you on the following point : if you don't care about
> > integrating it in your IDE and if you're not looking to
> > automated builds then you could probably use a sevlet test
> > runner to run cactus tests. As you said, that would remove
> > the client part of Cactus (it will still be there
> > but running on the server side ... :) ).
> >
> > What do you think ?
>
> To me they are both great products that I personally would
> like them to be togehter. That could make their future stronger.
> (I don't know if Jeff Schnitzer has any opinions in this matter.)
>
Here is what I suggest (if you wish, of course !) : Why don't you write a
web page about how to set up Cactus and JUnitEE so that one can use junitee
as a test runner ? Submit this to this list and I'll publish it to the
cactus web site for you.
Thanks for your help
-Vincent
> Kaarle
>
> > -Vincent
> >
> > ----- Original Message -----
> > From: <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, October 29, 2001 12:50 PM
> > Subject: html interface for Cactus (JUnitEE)
> >
> >
> > > hi!
> > >
> > > I have been looking at the sourceforge project JUnitEE
> > > that let's you access your testcases inside an J2EE
> > > container such as tomcat, weblogic or orion.
> > >
> > > Cactus does about the same thing but instead it uses
> > > the client interfaces for this task and just performs the
> > > tests inside the container.
> > >
> > > Cactus has some features that are not (to my knowledge)
> > > available for just using JUnitEE such as access to the
> > > request, server and other http objects.
> > >
> > > So I wanted to know is it OK to use JUnitEE as a UI for Cactus?
> > > The answer was YES!
> > >
> > > The good thing about it is that I don't need to have
> > > the classes in both client and server site.
> > > Everything is done in the server using a browser as UI.
> > > I have the added features of Cactus available.
> > > I can also run non-cactus tests in the server
> > > (extended from junit.framework.TestCase)
> > >
> > > What you need to do is include the JUnitEE servlet
> > > in the container that uses Cactus
> > > --------------------------------------
> > > Does this sound good?
> > > Is there something I could do to make it sound even better?
> > >
> > > regards
> > > Kaarle Kaila
> > > http://www.iki.fi/kaila
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
