Jitr (pronounced "jitter") is a JUnit Integration Test Runner. It allows your web application integration tests to easily run against a lightweight web container in the same JVM as your tests.
In a nutshell, Jitr improves your integration testing process by enabling:
Unit testing is an essential part of building quality software and is fantastic when you have a chance to isolate modules with mocks and stubs. However as we all know, unit testing can only take you so far. For modern web applications (MVC, SOAP, REST, etc.) how do you easily, quickly and efficiently integration test? Obviously you need to startup a web container somehow and use a client or raw HTTP to test from the outermost layer of your application. But this is where it gets frustrating. Debugging becomes a multi-step process, seeding a database for a single test becomes cumbersome, and testing just one test method in a test class becomes, well, sometimes impossible.
Jitr helps you speed up the red/green/refactor cycle by letting you run your integration tests in the same way you run your unit tests. Unit testing is fast and effient when you can use your IDE to run a single test method or test class with one click. No container to start up, no remote deugger to attach to a running container, no mess. Jitr gives you this speed and efficiency by starting the container before your test class is run and shutting down the container when all of your test methods are finished. Jitr even runs before and after your static @BeforeClass and @AfterClass annotated methods so you are free to setup and teardown your tests without having to worry about the container. Run the exact same tests from Ant, Maven or your IDE!
The big downside with integration testing a container in a continuous integration environment is that every build needs to run on a different port or else you will at some point suffer from port collisions. One of your builds will fail because Team Foo over in the corner has their integration tests running on port 8080 too (and they didn't even bother to tell you)! When Jitr runs the container for you, you can choose either a static port (like 8080 ) or you can ask Jitr to choose a random, unused port and inject the port number into your tests. No more failed builds with Address already in use !
Integration testing usually implies that at some point you need to go to a database. If you are doing a DAO module integration test with Spring, you can easily wire up a data source for testing that connects to an in-memory HSQLDB. When integration testing, why should I be forced to have a running DB on my local machine? Since regular integration tests startup the container in a different JVM, you would not normally have access to an in-memory database. With Jitr, since the container runs in the same JVM as your tests, you can easily use an in-memory database and still do database seeding before your test and cleanup afterwards. No more local DB installations!
Being able to inspect server-side state can be invaluable during integration testing. With Jitr, you can easily wire your test class with the same bean instances as the server is using. Inspect the database, evaluate server-side state and share any bean instances you want!
As nice as in-memory databases and lightweight containers are, integration tests aren't quite as useful when they don't run on the target production software. Jitr allows you to disable the container using a system property, allowing you to startup your own container using something like Cargo and Maven. You can startup JBoss or Tomcat, have Jitr wire your integration tests with Spring and let Spring inject a datasource that connects to a MySQL cluster. Target production software or lightweight and fast -- the choice is yours, even at runtime, and you get to use the same tests for both!
The most common web containers around may not be the container you have chosen to run with. That's why Jitr gives you the flexibility to easily create your own wrapper around your favourite container or easily extend one of ours to add any custom configuration or initialization steps you might need.