Most other web frameworks, particularly modern MVC frameworks (e.g. Rails, TurboGears, etc.), have first class support for performing full stack functional testing sans browser. These tests typically execute something like this:
- Drop functional testing database
- Populate functional testing database with seed data
- Start up web stack
- Execute tests that perform GET and POST calls to your site
- Check that something did or didn't happen
- Tear down web stack
- Repeat
.NET however is severely lacking in this area, requiring developers to jump straight from unit testing to browser testing with poor support for anything in between. Truthfully, "poor" support might be generous.
Thankfully, someone else has felt the pain and has worked to fill the gap. You can find a very helpful framework for performing this type of testing in ASP.NET MVC applications on Github, MvcIntegrationTestFramework. However, there are several things missing from this to make it as good a solution as it can be. Specifically, I prefer that any "unit" tests I run in my solutions run against their own database. This means updating the Web/App.config file, something MvcIntegrationTestFramework doesn't support out of the box. Thankfully I threw together this NUnit TestSetupFixture that performs steps 1-3 for me automagically (though step #3 is at the beginning of every Fixture).
Thankfully, someone else has felt the pain and has worked to fill the gap. You can find a very helpful framework for performing this type of testing in ASP.NET MVC applications on Github, MvcIntegrationTestFramework. However, there are several things missing from this to make it as good a solution as it can be. Specifically, I prefer that any "unit" tests I run in my solutions run against their own database. This means updating the Web/App.config file, something MvcIntegrationTestFramework doesn't support out of the box. Thankfully I threw together this NUnit TestSetupFixture that performs steps 1-3 for me automagically (though step #3 is at the beginning of every Fixture).
Why Run Functional Tests?
Ever had all your unit tests and data tests pass only to discover that no pages will load because you forgot to update your dependency injection? Well that's one reason, but another is that while Selenium tests have their place they are notoriously slow and don't always have access to the backend like your unit tests do.
Want to check that a user can't access a page after you revoke a permission? To do this in Selenium you have to login as an admin, navigate to the user's permissions, remove it, log out, login as that new user, and then try to navigate to that page as that user. And that's only if you don't care if they can access that page when they do have the permission. To do this in tests running at the level of MvcIntegrationTestFramework you can just hit the database directly to give the user a permission, make the page request as the user to make sure they can access it, remove the permission, and then try to access it again. It is much more straightforward, lends itself to data-driven automation, and your developers will be much more likely to build and run these kinds of tests.
Updating the Website's Web.config File
Here is a Gist I put together that shows how I perform this process from my functional test assembly. It's ugly but it works. The trick here is to modify the Web.config of the application under test while the harness is running, and then put it back to normal when it's finished running (or something goes wrong). Just don't commit while the tests are still running or you'll check in that change. But I know you all wait for your tests to finish before committing.
HTML Agility Pack
Something I have found very helpful for digging into HTML responses in these tests is HTML Agility Pack (available on nuget). It gives you the ability to verify page elements in a simple way. Just don't become too reliant on the HTML markup since your tests will become very fragile. This is just a quick way to get in there and run some quick assertions against your pages.
Still Don't Get It?
I've found these tests to be most useful for places where you want to test your full application stack but don't want to resort to something like Selenium to accomplish it. For situations like security/permissions testing this layer can be very powerful. You can hit every controller action directly all while having direct access to the database to tweak the little bits that make it all work.
