tags:

views:

40

answers:

1

I’m about to start work on an OpenRasta project (an xml over http web service). OpenRasta looks great but unfortunately worked examples seem few and far between on the internet. Looking at the test side of the project, if my handlers are returning strongly typed objects (not OperationResult), i.e.:

public class PersonHandler
...
 public Person Get(int id)
 {
 ...

How can I test for http status codes? (For example if the handler throws an uncaught exception). I’m not sure what level the tests pitch in at, and what needs mocking (using moq btw)

Any help appreciated, particularly coded examples!

+1  A: 

I faced the same problem, and ended up writing my tests as integration tests at a much higher level, actually making real REST/HTTP calls through a simple HttpWebRequest client. This allowed me to check the HTTP response headers / status codes and double-check the JSON/XML serialization from the client's perspective, which was just as important as whether or not the operations succeeded.

I started by returning OperationResult from all my handlers, and used these to wrap the strongly-typed objects. My handlers all inherit from a base class with a few helper methods that make it easier to return a custom error with a user-friendly error message. The more I coded this up, the more my handlers resembled a ASP.NET MVC controller. e.g.:

    public OperationResult GetById(int id)
    {
        try
        {
            // do stuff here
            return OKResult( // some strongly-typed resource );
        }
        catch(SomeException ex)
        {
            return BadRequestResult(SomeErrorCode, ex.Message);
        }
    }

Then in the test client, it's pretty easy to just check the HTTP status code. Obviously this doesn't help much with mocking. I'm not sure what the best solution is, in fact I've favorited this question in the hope that someone answers it better than I can - but this has worked pretty well for me so far.

realworldcoder
Thanks RWC. Yes, we’ve have opted for OperationResult for now but hopefully this is just a short term patch so we can get started. It’s not perfect, it leaves too much untested. For example, any interjection points that provide functionality pre/post the handler will be untested (and, as we are TDD, untested means unwritten!). Also, the interface uri’s will be untested.
Vman
Re testing against a real client: I did look into that but every dev has their own unique deployment and implementing a physical client on our build servers would be a pain. I may reluctantly pursue that again but have a strong preference for mocks.
Vman