views:

402

answers:

2

We're migrating our application into a JEE container, and looking for tools to use for unit testing (and integration testing) our migrated app. Our requirements include:

  • Ad-hoc testing: the ability to run tests manually, on demand (to be used by developers while developing code)
  • Batch testing: the ability to run a large (and growing) set of tests regularly
  • In-Container: integration tests that use EJBs as they are deployed in the container
  • Unit testing: Testing of classes not necessarily inside an EJB context
  • Nice to have: Simple to set up, integrates with ant/IDE
  • No requirement to test Servlets/JSPs - only POJOs and EJBs

What are you using to achieve testing in JEE environment? What technologies/setup have you deployed?

My research have uncovered Cactus and JUnitEE: have you had success setting them up?

+1  A: 

JUnit(EE) is what every major project($100mil+) I've supported has used. It's really a fantastic tool and knowing how to use it is invaluable when/if you decide to look for other job opportunities.

I supported a government financial system that used no unit testing but after a lot of pushing we finally implemented JUnit. The system I work on now is a large government agency modernization and we use JUnit for all of our unit testing. The two large firms supporting the modernization have essential made JUnit the standard across all of the sub projects. We've got ~200 developers using it without a hitch.

It's quick and easy to set up and once you understand it and you can leverage the features it will demonstrate how invaluable it is.

Doomspork
Thanks! So, am I correct in assuming you are using a combination of plain JUnit and JUnitEE (http://www.junitee.org)?
Armadillo
At this current time we only use JUnit with RAD (Eclipse based). I'm not familiar with any developer using JUnitEE but that's not to say it isn't a solid tool, most people just stick with JUnit. If it ain't broke, don't fix it they say!
Doomspork
A: 

We use normal JUnit for both unit tests and integration testing. We switch between the two using a VM argument, and have the tests annotated with markers for direct vs. server. We do have a custom TestSuite class though that finds and runs the tests based on this information, as it was easier and less error prone than manually maintaining which tests to run.

In our case we use Spring remoting to talk to servlets and EJB's (via the servlets), and testing both cases is simply a separate launch configuration within Eclipse.

We used JunitEE a few years ago, but eventually gave up on it in favor of just using JUnit throughout. This enabled us to have developers do all their testing without a server at all and run both unit and what I would call low level integration tests in their IDE. Then we let the build machine run the same integration tests against the same code now deployed in the actual server. This makes the development cycle much faster as we rarely need to run the server and deploy service code.

Robin