How to unit test Agatha handlers

[mwpowellhtx]

Hello,

I want to unit test Agatha handlers.

In the Web Api way, we might setup an HttpConfiguration, some routes, an in memory HttpServer, and HttpMessageInvoker invoke a Request, receive a Response back, and verify it.

In the Agatha way, how might we go about doing this?

Understanding there are network stacks potentially involved, if we can do this in memory as much as possible, that is preferred.

Best regards and thank you...

[bartdeleye]

Using ServiceLayerAndClientConfiguration.
For example:
https://github.com/davybrion/Agatha/blob/master/Tests/RequestProcessorTests/Interceptors/RequestHandlingInterceptorSpecs.cs

On Wed, Oct 15, 2014 at 3:57 PM, Michael Powell notifications@github.com
wrote:

Hello,

I want to unit test Agatha handlers.

In the Web Api way, we might setup an HttpConfiguration, some routes, an
in memory HttpServer, and HttpMessageInvoker invoke a Request, receive a
Response back, and verify it.

In the Agatha way, how might we go about doing this?

Understanding there are network stacks potentially involved, if we can do
this in memory as much as possible, that is preferred.

Best regards and thank you...

—
Reply to this email directly or view it on GitHub
#35.

[mwpowellhtx]

Perhaps I could rephrase a bit. I'm not sure we would benefit from necessarily intercepting requests since we've got extremely specialized requests/responses. What I am more interested in doing is setting up a web api client, preparing a request, invoking, and verifying the response. Doing so, it seems Agatha has its own flavor of client/server requests/responses, than those available from mvc, for example. Can someone clarify that aspect? Would be much appreciated. Thank you...

[bartdeleye]

I didn't mean that you need to use interceptors to enable testing of Agatha
handlers.
The provided link just shows some examples of how to configure and use/host
Agatha in your tests.

If you want to unit test your handlers, you can just instantiate and use
them as any other class without the need for other dependencies.

If you want to create integration tests, you can use the
ServiceLayerAndClientConfiguration to set up Agatha once for the whole test
suite (with in-memory communication). In each test just resolve a request
dispatcher and invoke it like you would in your real application.

Hope this helps.

On Wed, Oct 15, 2014 at 7:40 PM, Michael Powell notifications@github.com
wrote:

Perhaps I could rephrase a bit. I'm not sure we would benefit from
necessarily intercepting requests since we've got extremely specialized
requests/responses. What I am more interested in doing is setting up a web
api client, preparing a request, invoking, and verifying the response.
Doing so, it seems Agatha has its own flavor of client/server
requests/responses, than those available from mvc, for example. Can someone
clarify that aspect? Would be much appreciated. Thank you...

—
Reply to this email directly or view it on GitHub
#35 (comment).

[mwpowellhtx]

Yes, I believe I see the framework of request/response Handler there. Where we are registering as a service layer, that's what we pick up, the IRequestHandler. We only need to register with what for types? i.e. typeof(RequestHandler)?

Recapping where we are currently, we are trying to unit test involving the complete end-to-end, yes, realizing we are testing network stack as well, which could be problematic; basically involving the HttpClient and working its way out from there, request, response, etc.

We are bumping straight into ProtocolViolationException, but I'm not sure it's because I've been told that we should be sending a request with Content-Type of application/json. Everything else I am reading leads me to believe that we could Accept Content-Type a/j, which could plausibly be in the response. But nowhere do I read we should be setting that for HttpMethod.Get.

All that being said, if we can just test the request handler, provide the request itself, and receive the response back that we expect, that would be perfect. More than a brain dead "controller" unit test, by far.

Thank you...

[mwpowellhtx]

Reading the example, I feel you. We're getting 500 now consistently via several points of verifying. So we're at least consistently failing. I see no reason why web test client fixturing shouldn't work, so next first obvious thing is to make an effort to isolate the requests handlers apart from the web client.

[mwpowellhtx]

Next kerfuffle: we have service host and website derivations of the RequestHandler, apparently for Silverlight purposes. I'm not sure, testing the request handlers themselves, this needs to have any comprehension whatsoever of SL, per se. That being said, there is an override of CreateExceptionResponse going on for SL purposes. Is there an analog to that for RH unit/integration testing?

i.e.

public override Response CreateExceptionResponse(IRequestHandler handler, Exception exception)
{
    var response = handler.CreateDefaultResponse();
    response.Exception = new ExceptionInfo(exception);
    SetExceptionType(response, exception);
    SetExceptionFaultCode(exception, response.Exception);
    return response;
}

And/or, I seem to have read in places, there are other hooks we might look into for exception handling, filtering, that sort of thing, during request handling?

Edit: another school of thought is whether to be overriding the default RequestProcessorImplementation in the first place, for test purposes, anyhow.

Thank you...

[mwpowellhtx]

Closing this one. There are a couple of areas we'll need to discuss among ourselves, i.e. re: CreateExceptionResponse. Other than that, I believe this issue has been addressed.