ObMimic 1.0 Public Beta
Test-Doubles for the Servlet API
Fully‑configurable simulations of Servlet API objects, for plain‑Java “out‑of‑container” testing of Servlet API code.
ObMimic™ from is a library of plain Java™ implementations of the Servlet API’s interfaces and abstract classes. It provides ready‑made and comprehensive for “out‑of‑container” testing of Servlets, Filters, Listeners, JSF pages, and any other code that uses the Servlet API.
What Makes These Test-Doubles Special?
ObMimic’s test‑doubles provide complete, accurate, fully‑configurable and fully‑documented plain‑Java simulations of the corresponding Servlet API objects, whilst also providing additional facilities and instrumentation to help with the testing of your code.
We call these test‑doubles “mimics” because unlike or they automatically mimic the full behaviour of the real Servlet API objects. Our aim is for these “mimics” to be the ultimate set of test-doubles for the Servlet API.
Testing with ObMimic
You can use ObMimic to write comprehensive, detailed tests for your Servlet API code, using the same tools and techniques as for normal plain‑Java code, and without having to deploy and run your code inside a servlet container.
You can use ObMimic for both unit testing and integration testing, and with appropriate configuration you can even use it to test code that depends on a web‑application framework that makes its own calls to the Servlet API (for example, to test JSF pages).
At its simplest, your tests can obtain
fully‑functional “mimic” instances of
Servlet API objects using plain no‑argument
constructors — for example,
new HttpServletRequestMimic() to create an
Beyond that, your tests can programmatically:
- Configure each “mimic” for all relevant details of the corresponding Servlet API object’s logical state, and for any external factors that affect its behaviour (but with consistency between related Servlet API methods being automatically maintained);
- Pass the appropriate “mimic” instances to your code wherever it needs Servlet API objects;
- Inspect the logical state of the “mimics” as necessary to check the results of your tests.
This includes being able to configure and vary things that would normally be fixed or read‑only within a servlet container. For example, you can test your code against different “init parameter” values and other web‑application configuration details, against behaviours that can vary between different servlet‑containers, and against different Servlet API versions.
Similarly, it includes being able to inspect things that would be inaccessible or write‑only within a servlet container. For example, you can check the content that has been written into an HttpServletResponse, determine whether a response's Writer or OutputStream has been used, or check the content written to a ServletContext’s log.
ObMimic also lets you selectively record and examine the Servlet API calls made; lets you simulate the various exceptions that Servlet API methods can throw; identifies any Servlet API calls whose behaviour is incompletely or ambiguously defined; and provides a configurable, in‑memory JNDI simulation for any JNDI calls from your code.
Comparisons and Advantages
Compared to other approaches to testing Servlet API code:
- There are none of the restrictions, complexities, overheads or delays that arise when trying to test and debug code inside a servlet container;
- There are none of the limitations or uncertainties of trying to use basic stubs or general‑purpose mocks to simulate the Servlet API (in particular, there is no dependency on the precise sequence of Servlet API calls issued by your code or any code it might call, nor any dependency on your own assumptions and expectations of the Servlet API’s behaviour);
- There are no dependencies on any particular testing framework or web‑application framework (so you can use ObMimic with , or any other such testing tools, and regardless of whichever web‑application framework you might be using);
- There is no need to write and maintain test‑doubles of your own.
When to use ObMimic
If you want to unit‑test or integration‑test code that depends on the Servlet API (or uses a framework that runs on top of the Servlet API, such as JSF) but find that testing such code is harder, more restrictive or slower than for normal Java code, ObMimic may be what you’re looking for.
You can use ObMimic as much or as little as you like without affecting any other code, so it may be of use even if you just have some particular nooks and crannies that your existing tests can’t reach (for example, in configuration‑dependent or error‑handling code) — or if you just want the simplest possible way to create dummy instances of one or more Servlet API classes.
Even if you currently use mocks or stubs to simulate Servlet API objects, you may find that ObMimic is simpler for the simplest cases, or more suitable for any complex scenarios that mocks or stubs can’t readily handle.
To get started with ObMimic, . This is available at no cost and without any need to register, sign‑up to anything, or give us any of your details — subject to accepting its , you can just download and install it and you’re ready to start.
ObMimic lets you write comprehensive, fast‑running, detailed tests for code that directly or indirectly depends on the Servlet API:
- Using your normal testing and debugging tools;
- Without packaging and deployment, starting or stopping of servlet containers or applications, or networking overheads;
- Without restrictions on what Servlet API details can be configured and/or inspected;
- Based on an independent, strict interpretation of the Servlet API’s Javadoc;
- Based on the Servlet API’s overall behaviour (rather than against a precise sequence of expected API calls and your own expectations of their individual results).
- Including checks that your code does not depend on incompletely or ambiguously defined Servlet API behaviour.
“Mimic” implementations for all Servlet API interfaces and abstract classes, with:
- No‑argument constructors.
- Full implementation of all Servlet API methods (as defined by their Javadoc).
- Comprehensive facilities for setting and inspecting all aspects of the Servlet API object’s logical state.
- Simulation of Servlet API exceptions.
- Automatic consistency across related Servlet API methods.
Simulation of Servlet 2.3, 2.4 or 2.5 (with 3.0 and 3.1 to follow).
Selective recording and inspection of Servlet API calls and their results.
Selective interception and modification of Servlet API calls and their results.
Configuration of behaviours that vary between servlet containers.
Validation of Servlet API calls.
Built‑in JNDI simulation.