Web API controllers, abstraction and unit testing

I’ve had a lot in my mind this cold winter morning so get ready for another rant fest. I’ve been looking for options on how to build a REST based, unit test friendly, cloud future ready (for my purposes, ASP.NET core ready) web API service. I know there is a plethora of options out there for the common C# developer but they all seem to have some issues here and there. Here’s what I’ve ended up as of this morning.

  • OWIN for routing
  • Top Shelf for windows hosting
  • Web API for controllers
  • .NET interfaces for services that the controllers use
  • Service class implementations that are backward compatible with WCF (everybody calm down, WCF is not the most evil thing in the world)

So here’s the set up. I write interfaces that the web API controllers use because they are so much easier to test. I cannot find a good testing strategy for controllers. The issue I have with them is most of my methods return an HttpActionResult or an HttpResponse message which encapsulates the actual contents of the response. Not impossible to unit test, just fugly. So I’ve decided to abstract most of that logic behind an interface which i can easily inject and test.

This approach also gives me the ability to quickly write a net TCP based WCF service on top of it for now while I decide on how to move forward with the hosting. This now brings me to the next problem. Top Shelf. This is not open shift friendly. I understand that kestrel is a good replacement as long as you are doing ASP.NET core but what I don’t know is if my web API approach or even OWIN mappings would work. I see that MVC6 is pushing for a similar strategy but don’t see a support for web API (this just might be just due to my lack of checking though given I don’t even have VS2017 working anymore)

So yeah. Thoughts?

Leave a comment