General J2EE: Unit Testing a J2EE application

  1. Unit Testing a J2EE application (3 messages)

    Hello All, This post is just to gather your thoughts on some of the challenges that you encounter when unit testing your J2EE modules and the tools that you use to unit test your application. How do you test the servlet level classes? Do you use any open source tools for unit testing your J2EE application? Any feedback or thoughts are appreciated.
  2. Junit in Action[ Go to top ]

    I research for this topic some years ago, as a result I can tell you that this is the best resource I could ever found. http://www.amazon.com/JUnit-Action-Vincent-Massol/dp/1930110995
  3. I'm always keeping JEE code as thin as possible and not trying to test it. When all logic and functionality are placed in regular classes, they can be easily tested. When application is deployed to its real environment (I still test machine, but with application server), we just test its functionality manually. In my current project we are using EJB 3.0, but our ejb-module projects have only definitions of the beans with annotations for server injections (injected resources are placed to ThreadContext (utility around ThreadLocal)). These beans implement interfaces, which are defined in other normal java projects. And these projects also have other interface implementations, which are used by the beans, which are jUnit-ed and which are even used by stand-alone version of our application. I'm sure servlets can be kept thin as well
  4. The appserver generates deployment artifacts that is not easily tested, plus the deployment model itself is far from agile. Another approach is outlined here: http://www.atomikos.com/Publications/J2eeWithoutApplicationServer Summarized: with a lightweight stack (the article in the link uses Spring, Atomikos and JDBC/JMS but you can also include Hibernate) you can test ALL of the code, including the platform jars from within your build environment or IDE. In addition, there are no separate XML parsers at deployment time so the risk of XML problems is also eliminated. In my personal experience, this yields 4GL productivity with a 3GL like Java. More precisely: we recently re-wrote a Forté/UDS (4GL) application to Java (with this stack) and did the job within the same time frame as the original developers did - the difference being that we used a 3GL rather than a 4GL. Best Guy