Thursday November 26th

Wednesday November 25th

Should I unit- or integration test my ASP.NET Web API services?

Similar to ASP.NET MVC, Web API allows you to create relatively small building blocks, which can replace parts of, or be added to an existing default global setup. This makes it possible for us to test each component in isolation: controllers, dependency resolvers, filters, serialization, type formatters, messagehandlers and routing. Testing in isolation helps a great deal to keep the magnitude of things to stuff in your head limited, and when you break something, you are able to quickly pinpoint the origin of the error. What unit testing fails to prove however, is the correctness of your code when all the little pieces are put together and configured. And let it be that this is extremely important when you're exposing an API.


Like one of the comments on the blog, I prefer the higher-level spec/acceptance testing. However, I do like writing unit tests for specific bugs I've fixed to avoid regressions. I feel it's a good mix, and avoids 1) writing too many tests 2) running into the issue you described where unit-tested components work fine on their own, but not hen combined.

Commenting on Stories is limited for now and will open up to those recommended by the community. Learn how
Loading DotNetKicks...
brought to you by the Kicks Network