Integration testing Spring web app - java

I need to do an integration tests on my web application on each build.
Currently I have a set of JUnit tests, which tests various parts of an application before it constructed into war. What I need to do now is to test if application is in good shape after it is deployed into Web container.
The application is written using Spring framework, I've read a lot of docs about Spring integration testing, but all they talk is about testing of integration with databases etc. I've read about Cactus, but the info is pretty scarse as well.
Any pointers for a good tutorials and source code are appreciated.
Details of a software used by app: Spring 2.5, Hibernate 3.2, Maven 2.2, Tomcat 6.0
Many thanks!

You have two tasks to solve: A) Get the container running in an automated (maven based) process and B) run some tests against it.
We use selenium and maven-jetty-plugin for testing a fairly similar application setup. Works like a charm. You might find the same kind of plugins for tomcat, or just run in jetty.
The advantage of selenium is that it allows you to test the application in a very real environment with a real browser. You may find that tools that skip the "real browser" part are simpler to start with.

Related

how to use dropwizard for already developed web application

We have two web applications, which are already developed using Servlets and Jsp'.
generally we build them using ant and deploy on jetty server.
we would like to make build and deploying process easy. so how we can use dropwizard for our purpose or is there any other frame work we can use to make deployment and launching web applications easy.
thanks
in theory, nothing stops you from overwriting the ServerFactory and creating your own servlets there. You can then have that in DropWizard and things should work. (see DefaultServerFactory)
Problem with this is, that you are now using DW as a running container and you don't take any advantage of any features it offers you. So it really makes no sense to use that with your setup I think.
Alternatively, if you want to run and deploy into jetty, may I suggest you look into the maven jetty plugin? http://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html
It is not my favourite way of running it, but I have seen a lot of people using it. You essentially configure your application to use this plugin and add configuration on how to set up the connectors for jetty. Afterwards, all you need to do for running is "mvn jetty:run".

Comparison of Spring Boot, CXF over original Tomcat, Jetty

Can someone help me with advantages and disadvantages of using Spring Boot and CXF over original Tomcat/Jetty. Is it advisable to go for Spring Boot and CXF having embedded Tomcat/Jetty. Is it worth using it in Production environment. I'm building a SOA application. How does the performance compare in either of the cases.
It depends on how dependent you are on customizations. Spring Boot applies a certain defaults (which Spring classifies as sensible) based on what dependencies you have in your classpath. If you don't have an ugly legacy project I would go for bootsrapping your project with Spring Boot.
The features I've grown to like are that:
it really is easier to put up a Spring-based project
the profile-based configuration is really easy to use
it brings me closer to achieving a certain level of Continuous Delivery, just think about it: if you have a web project, you don't have to worry about setting up a Tomcat/Jetty on your machine. You just run java -jar package.jar
the variety of starter POMS opens up some nice possibilities for integrating modern technologies

What are the best methods for deploying java code to production?

Currently we have a Java Restlet API with dependencies controlled via Maven. When we update the API we run maven assembly:assembly which does the unit tests etc and produces a single jar file. We then upload this to the production server and run it using nohup.
Is there a better or more automated way of doing this? Is this where something like Hudson would come in?
Thanks
My experience goes with webapp-deployment. But same should hold true here. Use Maven, Cargo, Nexus (or Artifactory), Hudson and probably, Jira in conjunction of product release.
Automated release process are more reliable because there is no human factor involved that may forget a step.
We also use Liquibase for database versioning. And, if you are dealing with database changes in your application deployment. You'll realize Liquibase boosts so much confidence while running alter scripts.
I would suggest to go through the following resources
Automated Deployment with Maven - going the whole nine yards If you can, literally follow this pattern.
Maven 2 Effective Implementation -- this book really helped us a lot.
There are several Maven plugins to help deployment. The most general of them is Cargo, but there are also app server specific plugins for some concrete servers like JBoss.
Most companies I have worked for (actually, all) have had some sort of custom in-house built deployment system; even if build was done using a standard framework (like Maven in use at my current company).
Part of this is because there are many aspects that tie closely to company-specific infrastructure, capacity management and monitoring systems; and so even though there are open-source systems, there is usually something that needs to be tweaked.
It sounds like you are running your app on its own--it isn't part of any application server. If you aren't using an application server, there are probably some ways to get cargo and maven to deploy it for you, but you may be better off just using some shell scripts to deploy and run the application.
However, as your application grows, you may find a need for an application server like Jetty, JBoss, Glassfish, Tomcat, etc. When this happens, take a look at the cargo plugin for Maven because it will allow you to do something like:
mvn cargo:redeploy
That will package up your application, send it to the server and restart the app. If you want Hudson to do this for you automatically you can add it as a target to build.
Cargo can save you a lot of time when you have to frequently update an application server.

How do you unit test Java EE code?

I want to ask for your prefered way to test Java EE code?
I found only three project, that are trying to help to code unit tests in Java EE environment:
http://jakarta.apache.org/cactus/ : Last Published: 2009-01-18
http://www.junitee.org/ : Last Release: 2004-12-11
http://ejb3unit.sourceforge.net/ : Last Release: 2008-05-17
So I wonder,
is there any framework helping to write (j) unit test for Java EE code?
do you use embedded Java EE servers like jboss or glassfish v3?
do you mockup and inject by yourself?
Thanks a lot...
If by Unit Testing you mean... unit testing (testing a unit in isolation), then you actually don't need any particular framework since EJB3.0 are nothing more than annotated POJOs and thus can be relatively easily tested without any special fixture.
Now, if you mean something else - like Integration Testing or Functional Testing - then, yes, tools can help and simplify things (but you should really start to use the right terminology :) I'll assume that this is what you have in mind.
First, JUnitEE seems dead and obsolete and I'm not even sure it has anything for EJB3.x. Second, I'm not impressed by the Java EE 5 support of Cactus and having to deploy Cactus tests is painful (I think that Cactus was nice for J2EE 1.4 but is a bit outdated now). So this leaves us with Ejb3Unit which is in my opinion the best option, especially if you want to run out of container tests i.e. without really deploying the application (much faster).
If you want to run in container tests, then you could indeed use an embedded container and my current preference goes to GlassFish v3, even for Java EE 5 (I may be wrong but I'm pretty disappointed by the starting time of the latest JBoss releases so it isn't getting much of my attention). See the post GlassFish Embedded Reloaded, an appserver in your pocket for sample code (that you could use from your tests) or Using maven plugin for v3 embedded glassfish (if you are using maven).
Another option would be to package and deploy your application with Cargo and then run some tests against the deployed application (with Selenium or a BDD tool for example). This could be useful if you want to run end-to-end tests with a container that doesn't provide any embedded API.
So, to answer your last question, I would indeed use available tools, maybe a combination of them, for tests that are not unit tests and wouldn't mock/inject stuff myself, except if they don't cover some needs that I can't think of right now.
As you are interested in unit testing, I recommend JUnit. You can unit test the methods in the core classes. If you have difficulty in writing unit test cases using JUnit, then probably the design is not modular and it is highly coupled. First focus on your core functionality and test it using JUnit.
I've been facing the same problem of running integration tests based on JUnit in a Java EE 6 container (Glassfish v3, to be precise), and after a lot of browsing and searching, I could not find a solution that really suited me needs, so I wrote my own, now published as jeeunit on Google Code.
I wouldn't call it a test framework, it is really just a handful of classes providing the glue between JUnit and Embedded Glassfish.
The general idea is similar to Cactus, your tests run in the container and get triggered by a servlet from outside.
jeeunit supports JUnit 4, Glassfish v3, CDI and generates the standard XML JUnit reports just like Ant or Maven Surefire (in fact, I reused some code from Ant for generating the reports).
I had a requirement to test a CDI application and wrote a custom JUnit runner that runs everything outside of the web container.
http://jglue.org/cdi-unit/
It is suitable for Java SE and also supports dummy Request, Session and Conversation scopes for testing web apps.
It's small and fast, which is great when you have lots of unit tests.

Using jetty to install and run servlet tests programmatically

The jetty servlet container is quick and light enough to run in unit tests (indeed I do to serve up files).
It is possible to install actual servlets into it, programmatically (say in a test) and have it run them?
Yes. We do this on a regular basis with a number of tools. The simpest is probably HTTP-unit. When we deploy in jetty, we usually deploy larger parts of the application and run Selenium. HttpUnit is the simplest, but at some point your application complexity may warrant a more complete deployment. See the documentation section on embedding jetty
Why not use any HttpUnit, HTMLUnit etc.. Create an ANT script to do whatever is needed to run the test.

Categories

Resources