Configuring the Web Application for DryRunner

NOTE: This step is optional and is only needed if you are, in fact, using DryRunner for automation testing on your local machine.

DryRunner requires one change to the web application under test – an additional build configuration named Test.  DryRunner uses this configuration to do any required web.config transformations and debugging on the local machine.  Because the Debug configuration can sometimes be used for remote debugging environments, DryRunner chooses to use the additional configuration for acceptance testing.

To create the additional build configuration:

  1. In the build configuration drop down, choose Configuration Manager…
    bdd-configuration-manager
  2. Next to the Calculator project, under the Configuration column, expand the drop down and choose <New…>
    bdd-configuration-manager-2
  3. In the Name: field, type in Test. Make sure “Create new solution configurations” is checked.  Optional, you can choose to copy settings from another configuration (such as Debug if you are using the Debug configuration to test locally).
    bdd-configuration-manager-new-project-configuration
  4. Then click OK, then Close the Configuration Manager.
  5. Optional. If you would like to have a different configuration for automation testing (such as a different/temporary database), you can modify the Test configuration.  In order to do this, right-click on your web application’s web.config, and click on Add Config Transform.  You’ll then see a new configuration file called Web.Test.config.

You’re Done!

Whew! That’s may seem like a lot of work, but, like anything, it will become second nature the more you do it.  And, actually configuring behavior-driven development in your Visual Studio project takes less than 20 minutes.  As long as you have a good business analyst who understands Gherkin and how to write repetitive steps (to generalize and, thus, reuse your regular expressions as much as possible), most of your time will be used writing the methods that correspond to your steps.  Just treat it like unit testing and make sure you give yourself enough time in your sprint to do it well.

NOTE: Up to this point, notice we’ve not developed ANY code in our web application.  This is proper TDD procedure.  As a fellow developer, I encourage you to become comfortable with getting out of the common mindset of “seeing what it looks like” to validate business requirements and, instead, use acceptance tests.

NOTE #2: When you run your acceptance tests, it may take a minute or two for them to start up and finish.  The reason is that your web application must build first, then WatiN is attempting to instantiate COM objects in order to marshal IE instances.  Just be patient. (Hey, you can always click over to the IE instances and whatch the magic happen. 🙂 )

Download the full working Calculator solution (Visual Studio 2013).

Like What You See?

Subscribe to receive new posts in your inbox.