2 Replies Latest reply: Apr 13, 2012 9:09 PM by Dan Allen RSS

Fallback when serializing a TestResult failure

Dan Allen Master

There are certain cases when an attempt to serialize the TestResult to send over the Servlet protocol fails. For example, if the test method throws a MethodConstraintViolationException from Hibernate Validator, the java.lang.Method reference inside the exception detail cannot be serialized.

 

I think in these cases, we should have a fallback scenario where we try to summarize the failure as best we can, rather than reporting a failure in the protocol code itself. We could, of course, include a message that part of the detail was dropped and recommend catching the exception in the test to get the full trace.

 

Here's a test that exhibits the problem (don't catch the exception in the test):

 

https://community.jboss.org/message/729776

 

Here's the code in question:

 

ServletTestRunner.java

 

private void writeObject(Object object, HttpServletResponse response) 
   {
      try 
      {
         // Set HttpServletResponse status BEFORE getting the output stream
         response.setStatus(HttpServletResponse.SC_OK);
         ObjectOutputStream oos = new ObjectOutputStream(response.getOutputStream());
         oos.writeObject(object);
         oos.flush();
         oos.close();
      } 
      catch (Exception e) 
      {
         try 
         {
            response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e.getMessage());
         } 
         catch (Exception e2) 
         {
            throw new RuntimeException("Could not write to output", e2);
         }
      }
   }

 

At the very least we can rebuilt the TestResult with the following info:

 

  • status
  • exception message
  • exception or thowable class name

 

It's very unfriendly for developers to get Arquillian internal exceptions. This would make them feel more assured.