Unit Testing Web Applications is a Pain

Tags:

Aug. 28th 2007 in frame2, testing

I’ve finally reached the point where I hurdled my JAXB related validation issues, so another round of full unit testing is called for. Frame2 has two levels of testing:

  1. Unit tests that can be run outside of a servlet container. These include simple tests on discreet sections of the framework, and some tests written using (ironically) StrutsTestCase to simulate a servlet container.
  2. Tests that require a live servlet container. These include the TagUnit tests for checking the custom tag libraries and the Cactus tests that verify tag behavior.

The JAXB functionality is tested mainly through the first set of tests. However, as anyone who’s built a web app can attest, things work differently in a container. In this case, I’m talking specifically about loading resources. Using a getClass().getResourceAsStream() works just fine from the Ant console, but returns null when run within Tomcat. The solution, of course, is to use the ServletContext to load the resource, but obviously it’s not available when running outside of the container.

The simple solution was change the loading code to try to get at the ServletContext first, then fail to the getResourceAsStream() call. The best solution would be to refactor the appropriate unit tests so that they use the mock servlet structure – but I’m lazy today and mock objects can be quite tedious. Don’t get me wrong – I have nothing against mock objects. I would just rather get a new release of Frame2 out the door before devoting a lot of time to rewriting the test infrastructure, which is something most end users won’t care about.

  • http://www.closingbraces.net Mike Kaufman

    If this subject is still of any interest to you, another way you can now do out-of-container testing of web-application code is using my own “ObMimic” library.

    This provides plain-Java classes that “mimic” the whole Servlet API for precisely this purpose – and to make testing of web-applications less of a pain. You might find this a useful alternative or supplement to StrutsTestCase.

    ObMimic covers all of the Servlet API’s interfaces and abstract classes and completely implements all of their methods. It does this with plain Java objects that are fully configurable, fully inspectable, and have some additional features to help in testing (e.g. record/examine the Servlet API calls made to each object, report any ambiguous or questionable Servlet API calls, switch between Servlet 2.3, 2.4, 2.5).

    In particular, it does fully implement ServletContext.getResourceAsStream, so you could now test this outside of a container. Your test code can programmatically control what resource is to be returned for any given path, supplying this as a file, byte array, classpath resource, or a URL, or by specifing a root directory whose files are to be taken as the context’s resources. You can even configure it to return an InputStream that throws IOExceptions when read, so that you can test any corresponding error handling.

    Because ObMimic can handle even more complex uses of the API (e.g. request-dispatcher “forwards” and “includes”, listener notifications, servlet mappings, filter chains etc), you might also be able to use it not just for pure “unit” testing but also for testing more extensive paths through your code.

    As of May/June 2008 this is in private “beta” release, but if you want to take a look at it just let me know and we’ll set you up. For more details, see my recent blog posting.

SEO Powered by Platinum SEO from Techblissonline