SpecFlow, Webdriver and Mocks - is it possible?

The question in short is that we are stumbling upon BDD definitions that more or less require different states - which leads to the necessity for a mock of sorts for ASP.NET/MVC - I know of none, which is why I ask here

Details: We are developing a project in ASP.NET (MVC3/Razor engine) and are using SpecFlow to drive our development.

We quite often stumble into situations where we need the webpage under test to perform in a certain manner so that we can verify the behavior, i.e:

Scenario: Should render alternatively when backend system is down
    Given that the backend system is down
    And there are no channels for the page to display
    When I inspect the webpage under test
    Then the page ren开发者_如何学JAVAderes an alternative html indicating that there is a problem

For a unit test, this is less of an issue - run mock on the controller bit, and verify that it delivers the correct results, however, for a SpecFlow test, this is more or less requiring alternate configurations.

So it is possible at all, or - are there some known software patterns for developing webpages using BDD that I've missed?

Even when using SpecFlow, you can still use a mocking framework. What I would do is use the [BeforeScenario] attribute to set up the mocks for the test e.g.

[BeforeScenario]
public void BeforeShouldRenderAlternatively()
{
   // Do mock setups.
}

This SO question might come in handy for you also.

You could use Deleporter

Deleporter is a little .NET library that teleports arbitrary delegates into an ASP.NET application in some other process (e.g., hosted in IIS) and runs them there.

It lets you delve into a remote ASP.NET application’s internals without any special cooperation from the remote app, and then you can do any of the following:

• Cross-process mocking, by combining it with any mocking tool. For example, you could inject a temporary mock database or simulate the passing of time (e.g., if your integration tests want to specify what happens after 30 days or whatever)
• Test different configurations, by writing to static properties in the remote ASP.NET appdomain or using the ConfigurationManager API to edit its entries.
• Run teardown or cleanup logic such as flushing caches. For example, recently I needed to restore a SQL database to a known state after each test in the suite. The trouble was that ASP.NET connection pool was still holding open connections on the old database, causing connection errors. I resolved this easily by using Deleporter to issue a SqlConnection.ClearAllPools() command in the remote appdomain – the ASP.NET app under test didn’t need to know anything about it.