Setting Up the Project
For this demonstration, I’ll be using Visual Studio 2013 Ultimate Edition. However, what I’m going to show you will run in any of the Visual Studio 2010+ editions that support Web Applications + Unit Testing. (So, while you could use an Express Edition, you would need to open and create multiple solutions.)
Now, I could create a standard web forms application, however, performing general unit testing with MSTest can be difficult on the page-behinds due to the requirement of recreating the page lifecycle. Because I’m forward thinking and I would like to create unit tests to test not just external libraries, but my page logic as well, I’m going to use MVC.
Business Requirements
- Creating a simple calculator
- Two textboxes that allow numerical input
- A dropdown box between the two textboxes that contains operators
- A button that executes the calculation
- Calculation result is displayed
- Depending on role (e.g. “Simple” or “Advanced”), only certain operators are available. (To keep it simple, we’re not going to implement authentication, but just pass the role via the query string.)
- Simple
- Add
- Subtract
- Advanced
- Add
- Subtract
- Multiple
- Divide
- Simple
Create Solution
Create Acceptance Test Project & And NuGet Packages
We have the basic solution created. And, like I stated on the previous page, I don’t want to create an entirely different solution for my acceptance tests – I want the site self-contained. So, let’s add the additional project along with SpecFlow, WatiN, & DryRunner.
First, you’ll need to make sure you have the SpecFlow extension installed in Visual Studio. If you are unclear on how to do this, see the previous page.
- Right-click on the Calculation solution (make sure you right-click on the solution and not the web application project)
- In the context menu choose Add -> New Project
- In the left pane and under your preferred language (mine is C#), click on Test
- In the right pane, choose Unit Test Project
- In keeping with the default naming convention, name the project Calculator.AcceptanceTests
- You can then delete the created UnitTest1.cs class file as this will not be needed in the project.
- You are now ready to add the additional required NuGet packages: SpecFlow, WatiN and DryRunner
- Right-click on the Calculation.AcceptanceTests project
- In the context menu choose Manage NuGet Packages
- In the dialog, search for SpecFlow, WatiN and DryRunner and add them to your project. You’ll need to add:
- SpecFlow
- WatiN
- WatiN.Extensions.MSTest
- DryRunner
NOTE: At the time of this writing, Tim had not updated the NuGet repository. However, in March 2015, I added capabilities to DryRunner allowing you to specify build targets, override the Project Directory, and use macros for Pre- and Post-Build events. Tim did merge those changes to the source, but as I just stated, those changes weren’t deployed to NuGet. So, if you need those features, you’ll need to visit the GitHub repo, download the source, build manually and then reference the libraries in your AcceptanceTests project.
As stated on the previous page, there is a CAS security issue with WatiN because of how it is added to the project automatically with NuGet. Visual Studio will throw a hissy-fit because WatiN is using COM to launch an instance of IE for automated testing. In order to overcome this hurdle, we’ll need to remove the references from our project and then re-add them. Then, we’ll need to set a security property.
Edit the App.Config
There are two final things you’ll need to do: 1) provide WatiN/DryRunner with the URL of your testing site (more about this a little later); and, 2) tell SpecFlow which unit testing framework you’re using (e.g. MSTest or NUnit). To do this, you’ll need to edit the app.config. Open the app.config of you acceptance tests project and change it to look like the following:
NOTE: If you’ve already added some SpecFlow features, you made get a warning message stating that your changes may require your feature files to be regenerated. The feature code-behinds are what will make our method calls for our steps (again, more about this later). For the time being, go ahead and click Yes.
Again, the two things we’ve done are: 1) created an appSetting that configures the URL of our testing server (which allows us to update it in one place); and, 2) tells SpecFlow that we want to use the MSTest unit testing engine.
Our project setup is now complete. We can now discuss our acceptance tests in a little more detail and begin building our project.
Joshua, you may already be aware of OWIN which offers much better approach to unit testing web sites & services. OWIN is a development framework, not an automation tool, but it provides for ability to separate implementation & deployment. Tests which invoke http end-points, for example, don’t require IIS hosting, but neither do they care whether the endpoint is self-hosted, IIS-hosted, or just in-memory for a la unit testing.
We use OWIN for new implementations, and we are refactoring older ASP.NET apps to OWIN. DryRunner continues to be a good solution for non-OWIN implementations.
Absolutely! And great alternative. The problem, however, is exactly what you said, “OWIN is a development framework, not an automation tool…” Unfortunately, many of my clients still choose (are required) to use the standard Microsoft ASP.NET assemblies instead of the vNext implementation (Katana) etc. Thanks for the great input. Perhaps when I get some time, I’ll do a BDD example with OWIN.
[…] Specializing in Windows Azure, Microsoft ASP.NET, Data, SharePoint, & Team Foundation Server Previous […]