I'm currently helping a team move toward a continuous integration/build/deployment methodology. They've been doing unit tests for most of their UI code and some of their services code since project initiation, the CI runner runs those tests after every build, and build failure alerting is set up and working, so they are not in a bad state. However, this morning we all arrived at stand up and were deflated to hear from our tester that the entire product was none functional. Being the tools guy for the team, I sat down with the last developer to commit and started working through the problem.

Pretty quickly we realized the found the problem:

 "InvalidOperationException: Cannot have two operations in the same contract with the same name...",

Two developers had committed the a method of the same name in the WCF Service Contract, (the yourService.svc.cs) file which through the above exception when the ASP .NET tried to resolve the request. Simple mistake, by why didn't our automation catch it?

Well, we'd been pretty disciplined making sure our functional classes were decoupled from the web services and that our unit tests worked in isolation, which is a great best practice. However, we'd never produced any tests that actually called the deployed web service after the build. This meant we were missing whole categories of potential issues with our code and deployment process. In particular, I've seen issues around bad web.config files being checked in and no one noticing till the entire test site was on fire.

I've been writing BVTs (build verification tests) all day to prevent these sorts of issues from popping up again. My conclusion for the day- unit testing is great, but your product works in integrated mode. Test there, too.