In a previous blog post I discussed how to “push” environment specific settings into the execution of a SpecFlow scenario.
This post is more an “end-to-end” example of a situation where this might be handy to use. It will also give me a chance of showing off a another favorite of mine, TeamCity.
The details however, are in the other post.
About SpecFlow in TeamCity
Since a SpecFlow feature is really just implemented as unit test, and depending whether or not your unit test provider supports it, you can organize your scenarios and/or features by tagging them. The tags will then be translated to categories (depending if the unit test framework supports it but generally not an issue).
So, to execute SpecFlow tests in TeamCity all you really have to do is to execute some unit tests.
And…if you choose MSTest or NUnit as your provider they come OOB with TeamCity plus they both support tagging/categories.
In TeamCity I’ve got an idea of the following (as illustrated by the image above) build configurations:
- A: outputs the application (zip file) + the Specs (the DLLs needed)
- B: outputs the deployment script (PowerShell)
- 1: Deploys the application to the TEST environment + verifies the deployment (via SpecFlow)
- 2: Deploys the application to the PROD environment + verifies the deployment (via SpecFlow)
note: I’ve covered the details of this setup in a previous post.
A and B are already implemented and working, time to get 1 and 2 working now.
Below are the build steps for 1 & 2 in overview. We’ll be focusing on verifying the deployment which will be done through a test (implemented as a SpecFlow feature).
This build configuration looks the same for both the test and production environments, it’s only a matter of changing some configuration values.
Configuration Values (a.k.a. the Environment Settings)
We’ll have a look at how the build configuration is implemented for the test environment and then you can guess how it looks for the production environment.
The source control repository has a folder, environments, that contains a sub-directory, test, which holds all the configuration files for that given environment.
note: the highlighted file above is the SpecFlow settings file that was introduced in the previous post.
We now need to “pull” that file (from the test directory) and present that to SpecFlow before it executes the scenario.
In the build configuration for 1 we have to edit the checkout rule to only “pull” files from the /environments/test folder and by doing that we will get the setting file for the test environment just-in-time for our SpecFlow feature to execute.
Executing a limited set of features/scenarios
So now when I execute the build configuration 1 or 2 it will:
- pull the artifacts from build configurations A and B (web application, deployment scripts, and the SpecFlow DLLs)
- pull the environment specific configuration files from the source control repository (1 pulls /test and 2 pulls /prod)
- deploy the application
- execute the features/scenarios tagged with @deployment using the config file for the current environment (just-in-time)
Lastly, the code and other things can be found right here.