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.
Vincent Massol wrote: [cut] >>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. JUnitEE does not care about this, it is just a test runner to execute your tests. What your tests are doing and how they are implemented is up to you as long as they are JUnit tests. >>- 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 > > browser > > 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. I did not realize that, but that's fine. >>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 ... :) The Ant task is included in the latest release of JUnitEE. [cut] >>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 ? 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. [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. >>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? What I wanted to say: to make it possible to use the Cactus servlet test runner in the way you use JUnitEE today, you would have to get rid of the special test case superclass. And this would be a complete change in Cactus architecture because the core decision of Cactus is to have a special test case class which in the background does the communication with the server. This is transparent to the person writing the test (despite the fact that you have to set a property), but it's there and it has it's consequences. >>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). 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. > - 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 : > http://jakarta.apache.org/cactus/howto_tomcat.html > > 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: > > <junit> > <classpath> > cactus > jetty jar > </classpath> > > my tests > </junit> > > 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). > That's a cool idea! If you have a servlet-only application I'm sure it works fine. [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 ... 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. 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. -- Oliver -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
