-
Notifications
You must be signed in to change notification settings - Fork 0
Development
The source code of SpecFlow is included in a single Visual Studio 2008 solution (TechTalk.SpecFlow.sln), located in the main folder.
Besides the source code, the SpecFlow reporsitory also contains a "Samples" folder where you can find code samples (might be included into the installer later).
The source code is divided into the following categories:
- Installer - All code related to the SpecFlow installer o Location: "Installer" folder o Projects: + SpecFlowSetup - the setup project + DevenvSetupCustomAction - a custom action to call "devenv /setup" during installation
- Generator (aka Parser) - All code related to generating unit test classes from feature files o Includes Gherkin parser o Does not have a static dependency on the "Runtime" components to allow side-by-side runtime versions o Location: "Parser" folder
- VsIntegration - All code related to Visual Studio 2008 integration o Includes SingleFileGenerator for the ".feature" files o Location: "VsIntegration" folder
- Runtime - All code related to the execution of the generated tests o Includes + the "TestRunner" class (entry point of the generated test methods) + the dynamic binding resolution and execution logic + the binding attributes + the FeatureContext/ScenarioContext classes + the tracing logic o Location: "Runtime" folder
- Tests - Unit tests for the generator and the runtime components o Location: Tests o Projects: + ParserTests - tests for the parser and the generator + RuntimeTests - test for the runtime component
- Reporting - All code related to SpecFlow reports o Includes + Step Definition Report - a report about usage and binding of scenario steps + NUnit Execution Report - a report that visualizes the nunit execution result in SpecFlow style o Does not have a static dependency on the "Runtime" components to allow side-by-side runtime versions o Location: "Reporitng" folder
Here is a list of code structuring conventions that we follow:
- The projects are named, like the full namespace (e.g. TechTalk.SpecFlow.Parser), but located in a folder with the short name (e.g. Parser). This is useful to stay below the VS path length limit.
- All external dependency (like nunit.framework) is located in the "lib" folder.
- All project includes (as a link) the VersionInfo.cs file from the root folder (to make the version changes easier).
- If you have finished working on a branch (that has been pushed at least once), you should delete it after merging back. Here is a description how: Remove a remote branch
installer tests
- Run the installer on a machine where one of the previous versions were installed * it should upgrade
basic tests with NUnit
- Create a new solution with a new class library project
- Add references to TechTalk.SpecFlow.dll and nunit.framework.dll
- Add a new feature file from the VS "add new item" dialog * the generated classes should compile
- Run the unit tests * there should be one test (AddTwoNumbers) * it should result in a pending state (no binding for steps)
- Add a new "step definition" from the VS "add new item" dialog * project should compile
- Comment out "pending" steps in the step definition file
- Run the unit tests * test should pass
- Add a new "event definition" from the VS "add new item" dialog * project should compile
- Run the unit tests * test should succeed
basic tests with MsTest
-
Add a test project to the solution (remove default items)
-
Add references to TechTalk.SpecFlow.dll
-
Add an App.config file to the project with the following settings
-
Add a new feature file from the VS "add new item" dialog * the generated classes should compile
-
Run the unit tests (Test/Run/All Tests in Solution) * there should be one test (AddTwoNumbers) * it should result in a pending state (no binding for steps)
-
Add a new "step definition" from the VS "add new item" dialog * project should compile
-
Run the unit tests * test should pass
The following steps has to be done to release SpecFlow:
- make sure that the solution compiles and all unit tests pass
- define a new version number based on the VersioningPolicy
- review/update the changelog.txt file with the version number and the date
- update the VersionInfo?.cs file
- set the new version number in the SpecFlowSetup project properties * will ask to generate a new product code, allow it (required for upgrade install)
- compile the SpecFlowSetup? project
- apply some SmokeTests for the created release
- compress the msi + setup.exe together to a zip file named like: SpecFlowSetup_v1.0.2.zip
- tag the master branch with a tag like "v1.0.2" * you can push local tags with "git push --tags"
- publish the zip to the website (how?)
- announce the new release (how?)
Bugfix releases: increase the 3rd number (like 1.0.1 -> 1.1.2)
Minor feature releases: increase the 2nd number (like 1.0.2 -> 1.1.0)
Major feature releases: increase the 1st number (like 1.1.2 -> 2.0.0)