In-Container Testing with JUnit


News: In-Container Testing with JUnit

  1. In-Container Testing with JUnit (14 messages)

    Learn how in-container testing with JUnit adds a layer of integration testing that is most useful in practice. Examples used in this article will teach you how to make JUnit tests access objects running inside a J2EE container

    Julien Dubois writes:
    Thanks to the JUnit framework, it has become quite easy to write unit tests for simple Java applications. However, where real-world enterprise applications are concerned, the typical JUnit testXXX() method will not be as helpful because those applications require that objects run inside a container. Author further discusses how to apply those techniques using Oracle JDeveloper IDE.
    In this article, I will describe the application of in-container testing in order to make JUnit tests access objects running inside a J2EE container. The example used here is a Struts-based Web application, which is fairly common among enterprise applications, but the techniques discussed are relevant to any J2EE project.
    Read the article In-Container Testing with JUnit

    Threaded Messages (14)

  2. JUnitEE[ Go to top ]

    Personally, for in-container testing (particularly of ejb components - and messaging) I have found JUnitEE to be one of the easiest and quickest tools to configure-
  3. Cactus[ Go to top ]

    I need to start doing server side testing. How does JUnitEE compare to Cactus?
  4. Cactus[ Go to top ]

    Cactus also lets you write Unit Tests to unit Test Servlet. JSP, and Servlet Filters directly. Using a Struts extension to cactus, you can unit test Struts Actions directly. This is an additional value add for the web layer of J2EE apps. JUnitEE only provides an environment to run standard JUnit inside the container but no way to unit test Servlet, Action classes directly. Cactus will even work J2EE Security and supports Basic and Form Based Auth.

    Cactus also provides a Mock framework for running these J2EE Web unit tests outside the container.
  5. JUnitEE[ Go to top ]

    As mentioned- cactus is probably a bit more robust- and may be more appropriate for testing web tier components- such as servlets- as JUnitEE provides a servlet that lets you "tunnel" in to the container and call JUnit tests. It is very good for testing ejb components and messaging in this manner and I found it to take <1 hour to figure it out and deploy- whereas configuring cactus is a bit more cumbersome in my opinion- and would only use it if I were testing such web-tier items.
  6. JUnitEE[ Go to top ]

    I liked and hated both Cactus and JUnitEE although I have less experience with the later.

    JUnitEE is good if you have someone who has created a deployment script already for you and you can just run the test. Also the person needs to have created a report template for you as well. (Hopefully someone creates a Maven plugin to do this so it will be integrated with the rest of Maven's site report)

    Cactus I find to be a better tool when you are automating tests and try to keep things more generic for multiple application servers. However, its fiendishly more complicated to set up, not really Cactus' fault, but more of the fault of the application server vendors itself (I do wish someone does create a standardized API to stop, start, deploy, undeploy to servers like Vincent Massol stated in his blog a while back). If you can get Cactus working on your environment especially with maven you'd probablly like it a lot better since you'd get your reports for free as well, but like I said, setup is a killer.
  7. JUnitEE and cactus[ Go to top ]

    not only is cactus a pain to setup, but it also takes a long time to run your tests. this is again due to the nature of the j2ee servers. assuming you're servers aren't running, you've got to start them up, deploy your components, run the tests, and then shut them down. we have slsb's that we need to test on a wls environment, and this is painfully slow.

    i looked into Alex Rupp's (sp?) article on using openejb (and axion db) for testing incontainer. on the surface it looks really exciting, but there's not much documentation on configuring openejb, and maybe everyone there is busy working on the geronimo release, but it's hard to get answers to the mailing list ( i can't even subscribe to the list using my work email address, maybe it's down/moved?). my simple example test worked ok, but i had issues resolving the dtd's since i'm behind a proxy. it would be nice if there were docs, forums, etc up for this awesome ejb server.

    still, each of these technologies provide something of value. the openejb approach, using an intra-vm container, is very very fast, and provides a test driven development environment. using cactus for tdd would be: write a test, start the test, get a coffee and snack, come back see the results, change the code, redo. cactus provides a reality check with your actual application server (and possibly database servers). if you decide you need to switch to a new database driver, or perhaps switch to a new database, how can you quickly see where the problems are? run the bundle of cactus tests and see how it goes.
  8. OpenEJB[ Go to top ]

    Although I like the concepts put forward by N.A.Rupp's article, (I am actually waiting for Geronimo to come out so we have an EJB container that supports 2.0). I still like to have Cactus as one of my tests. Primarily, its good to test on the server you are deploying on, especially with the slight incompatabilities with all the application servers you want to make sure your generated app server specific deployment descriptor works properly.

    I wouldn't really use cactus for running unit tests though, like it was specified earlier its too slow because of the startup and shutdown times of the application server. Its still good to run on your nightly build server where you don't really have to watch it run (once everything is set up).

    I think any large project should have a build expert that can set up automated integrated test running using Cactus and be focused on improving the development infrastructure. (i.e., don't let the person get bogged in the application development stuff, make him focused on builds and performance reporting).

    Also, I personally like to do most of my coding out of container as well. Usually if it is a brand new project methods can be applied to allow for that, but if you're not there from the beginning, you have to adapt as much as possible and from my current experience JUnitEE would be the best for retrofitting in developer unit tests along with either JFC/HttpUnit (if you're fortunate that your project uses standard HTML and can work without javascript or an automated mouse and keyboard robot to run through the web site or GUI client).
  9. For out of container testing, I can recommend MockEJB framework that I developed ( Unlike OpenEJB, this is a mock container geared specifically for testing. So I use MockEJB for on-going development and Cactus for integration testing and verification of the deployment (MockEJB does not read deployment descriptors).

  10. Personally, I prefer to do as much testing as possible out of the container - and write my code accordingly.

    Integration tests (end-to-end) is where running in the container is tested - but hopefully not too much behaviour is being tested here (that wasnt already tested in the out-of-container tests).

  11. In our projects, we have had the same need to be able to execute code inside the container, especially testing of local interfaces is hard to do, unless you want to provide a remote interface just for testing.

    But having to redeploy the test case to the server, every time you have to change a testcase, as you have to do with the existing frameworks that I know of, quickly gets anoying. So what we have done is to write a TestFacade session bean with remote interface, which uses DynamicJava (hosted at sourceforge) to execute dynamicjava scripts. We then have an extension of Junit's TestCase which is able to read the scripts from the filesystem, and ask the TestFacade to execute it.

    Every TestCase we have is then an extension of our own TestCase and a set of dynamicjava scripts, containing the business logic of the test.
  12. This sounds interesting. I will check it out.

    We are using using ServerSideTest JUnit extension.
    It works fine except for the re-deployment. And For Weblogic Server, this become real pain as it takes long time to do the ejbc.

  13. Correction, Not ServerSideTest, it should be ServerTestCase. Sorry.
  14. hi,

    how do you manage to use ServerTestCase?
    I must miss something : I can't even run the ExempleServerTestCase.
    I always get ClassNotFoundException.
    Can somebody help me, please?

  15. TestSessionBean[ Go to top ]

    How about ServerTestCase? It's simple to set up and easy to use. Just extend ServerTestCase instead of TestCase and you are in-container.