Integration Testing in a Development Environment With SpecFlow — Part 2: Local IIS (Windows IIS)
Last
time we got our hands dirty with Cassini — only for me to share the harsh
lesson I learned which was to not use it. I then kindly offered no alternative.
But to clear my conscience now I will — in this short post, I’ll show you how
to integration test in your development environment using Local IIS — the one
installed with Windows.
Configuring Visual Studio to use Local IIS
To get cracking with IIS the process is really simple:
- open the properties for the web project
- navigate to the web tab
- check “Use Local IIS Web Server”
- hit the “Create Virtual Directory Button”
Above: It is as easy as this to host
your web site with Local IIS
Note: When hitting the “Create Virtual Directory” you
may be told you need to install some Windows Components. You can do this easily
by “turning on Windows features” in the control panel’s Programs area (in
Vista). The options required will be child nodes of “Internet Information
Services”.
This process does seem a little too easy, so you can put
your mind to rest by starting the application (F5) and/or looking at the
virtual directories installed via the IIS Management Console. Easy.
Updating the Specs to Accommodate IIS as Integration Testing Server
With the site now hosted on Local IIS, the server is sitting
there, happy to serve requests aimed at our web site whenever. Knowing this
means none of the Cassini set-up code is required. All that is needed is
for the integration specs to be pointed to the virtual directory of the web
site.
For these two requirements to be met, the
WebServerStepsEnvironmentManger can be done away with and deleted (if you don’t
at least comment it out, SpecFlow will still see the bindings and process them);
while the home page url constant in the step file can point to the home page located in the virtual directory. The slightly-updated step file now looks
like so:
namespace
Specs.Integration.Steps
{
[Binding]
public class SpecialHomePageInputValuePerformsSpecialRedirect
{
private IE
_browser;
private const string SpecialInputTextBoxID = “abcdefg”;
private const string HomePageUrl = @”http://localhost/SpecFlowIntegrationTesting";
public
SpecialHomePageInputValuePerformsSpecialRedirect()
{
_browser = new IE();
}
[Given(@”I
am viewing the home page”)]
public void
GivenIAmViewingTheHomePage()
{
_browser.GoTo(HomePageUrl);
}
[When(@”I
enter (.*) in the special value text box and submit the form”)]
public void
WhenIEnterWebSecurityEssentialsInTheSpecialValueCheckbox(string secretInputValue)
{
var specialInputTextBox =
_browser.TextField(SpecialInputTextBoxID);
specialInputTextBox.TypeText(secretInputValue);
_browser.Buttons.First().Click();
}
[Then(@”I
should be redirect to www\.OWASP\.org”)]
public void
ThenIShouldBeRedirectToWww_OWASP_Org()
{
var currentBrowserUrl = _browser.Url;
// sometimes browsers and url casings can mess up
tests — lets go toUpper() to remove any potential issues
Assert.IsTrue(currentBrowserUrl.ToUpper().Contains(“WWW.OWASP.ORG"), “We were not redirected to the OWASP web site”);
}
}
}
Does it still Work?
Of course it does:
Above: Same results, different server
A Few Quick Life-Savers
If you do take this approach, remember or refer back to
these key points I have personally encountered:
- In web.config you may need to copy your http handlers and modules
from the System.Web section to the corresponding locations in System.WebServer
section (NHibernate/Castle Active Record was one) - If you create a .NET 4 application, make sure the application
pool it uses is .NET 4 enabled via the IIS Management Console - The application pool will also need permissions to access your
database (if there is one) - Due to the extra url segment, your root-relative css styles may
not work. Go relative if you can
Conclusion
We’re smart. And we know that using Cassini for testing is not smart.
We also know that we need to replicate the production environment as closely as
possible when integration testing.
Using the IIS installed with Windows takes us a lot closer
to that ideal. If it is the same version that you will be hosting your
application on in the wild, then you’ve hit the jackpot.
With this approach, we have also seen that configuration is
very easy, and setting up integration tests is too. Compared to all the faff
with Cassini, this is definitely an easier ride.
But this story is not yet fully told. Scott
Gu announced there is to be an IIS Express — that can be used in the same
way as Cassini with the full capabilities of IIS.
IIS Express is already here….if you use Web Matrix.
But there’s still no (official) “fix” to make it work with Visual Studio. So stay tuned for when there is and I compare that option.
