by Anton
2. October 2013 15:16
Ususally we spec out features using SpecFlow. Then we write out the step definitions and code the feature (or vice versa). When we programmed the “export entries” feature for the portal management area of discoverize, we did so using TDD (test driven development) with unit tests. Since it is an MVC project, we could mock the controller (and the services needed). It all went well, and in the end the feature was coded. Yet, the SpecFlow scenario had no step definitions to fulfill it.
@unittest
Scenario: Export every property from every entry
Given I have 2 entries
When I export all properties
Then I get a file with 3 lines
And the first line are the column names, that is the property names
And each other line represents the data of one entry
Usually we write steps that follow links and push buttons in the web interface – as the user would do. This time – since we already had good coverage of the controller action – we decided to hook up the unit tests as the step definitions.
This is quite easy if you know how. We used the @unittest tag to suppress starting the IIS Express and browser for this scenario. Since our unit tests are in a different project than the SpecFlow tests we did everything according to this documentation. After a little refactoring in the unit tests to extract appropriate methods for the steps and adding the step attributes the SpecFlow scenario went green.
[Then(@"I get a file with (\d+) lines"), Scope(Tag = "unittest")]
public void FileHasLines(int numberOfLines) {
var lines = _exportText.Split('\n');
Assert.AreEqual(numberOfLines, lines.Count());
}