Home/ Questions/Q 245173
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T21:04:00+00:00

We’re migrating our application into a Java EE container, and looking for tools to

  • 0

We’re migrating our application into a Java EE 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 Java EE environment? What technologies/setup have you deployed?

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0