, ,

Until now we had many excuses for not writing integration tests:

  • we prefer unit tests over integration tests
  • our business logic (aka services) is separated and thoroughly tested
  • we keep our ontrollers on a diet
  • UI consists mostly of standard elements (aka widgets) which are tested on their own
  • we are lazy

But there was still too much space for error. From time to time a seemingly innocent change in Razor view (or HTML helper, or filter, or “something completely irrelevant”) unexpectedly broke one of the pages. If all tests are green why bother starting an app at all? Our main goal is to pass all tests. Or is it? 😉

There are many benefits of attending a user group meeting i.e. good excuse to drink beer. But last Thursday on Warsaw .NET User Group I learned[*] the lazy way of integration testing ASP.NET MVC applications. Adam Kosiński showcased the MvcIntegrationTestFramework. It’s probably originated from Steven Sanderson’s post but since then had many mutations and forks on GitHub. One of them is even released as NuGet package. I went for it:

PM> Install-Package FakeHost

Which added two DLLs to my project and then I could write integration tests as simple as follows:

It’s slow, it’s somewhat brittle but relatively concise, works OOTB and thanks to it we found a few bugs already.

[*] I cannot fail to mention Maciej Aniserowicz talk which convinced me that I should have used Nancy instead of ASP.NET MVC in the first place but… it’s to late to apologize 😉