|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 14
Messages: 14
Messages: 14
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
In-Container Testing with JUnit
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
|
|
|
Message #135439
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JUnitEE
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.
|
|
|
Message #135454
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cactus
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.
|
|
|
Message #135455
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JUnitEE
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.
|
|
|
Message #135472
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-Container Testing with JUnit
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).
-Nick
|
|
|
Message #135526
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-Container Testing with JUnit and DynamicJava -> no redeploy
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.
|
|
|
Message #135557
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JUnitEE and cactus
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.
|
|
|
Message #135612
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OpenEJB
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).
|
|
|
Message #135626
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
OpenEJB, Cactus and MockEJB
For out of container testing, I can recommend MockEJB framework that I developed (www.mockejb.org). 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).
Alexander
|
|
|
Message #135832
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-Container Testing with JUnit and DynamicJava -> no redeploy
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.
Chester
|
|
|
Message #135837
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-Container Testing with JUnit and DynamicJava -> no redeploy
Correction, Not ServerSideTest, it should be ServerTestCase. Sorry.
|
|
|
Message #177260
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-Container Testing with JUnit and DynamicJava -> no redeploy
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?
TIA
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
