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.
- 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.)
- Create a new project
- The project type will be an ASP.NET Web Application. (Keep in mind that I’m using Visual Studio 2013. Your options and process will be different if you’re using VS 2010 or 2012.)
- Name the project Calculator.
- Template type will be Empty.
- Add folders and core references for: MVC. (Once you select this, the template type will deselect. That’s okay, we’re simply saying we don’t want the extra OAuth, etc. junk that comes with the MVC template.)
- Add unit tests
- Test project name: Calculator.Tests
Once the solution has been created, your Solution Explorer should look similar to the image on the right.
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:
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.
- In the Calculation.AcceptanceTests project, expand References
- Remove Interop.SHDocVw and WatiN.Core
- Now, we’ll need to add them back
- Right-click on References and click Add Reference
- Choose Browse… to locate the assemblies manually
- Go to your solution folder, then find the packages subfolder
- Inside the packages subfolder, open the WatiN.x.x.x subfolder
- Inside the lib subfolder, find the corresponding .NET version
- Your current location should be something like %SolutionDir%\packages\WatiN.x.x.x\lib\netxx
- Now re-add Interop.SHDocVw.dll and WatiN.Core.dll (hold down Ctrl to select both and add them add the same time)
- Click OK in the Reference Manager
- We now have to set a property for the Interop.SHDocVw
- Either right-click on the Interop.SHDocVw and choose Properties; or, click once on the reference and press Alt+Enter
- There will be a property called Embed Interop Types which is currently set to True
- You’ll need to change this value to False
I know the above steps may seem tedious, but once you do it a couple of times, it literally takes you less than a minute to do all of this. Overall, it’s relatively simple.
Once you’ve completed all of the above steps, your solution should look like the image on the right.
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.