-
Notifications
You must be signed in to change notification settings - Fork 17
Writing Features
When you add new feature files, you need to edit a property on the file. Clear the 'Custom Tool' value, else you will get build errors.
You can use the example project as a base to write your own features.
Many feature steps contain an 'alias' variable. When records are created or retrieved, they will be added to a cache. The key will be the specified alias. In example: "Given a {entityname} named {alias} with the following values" will create a record and add that record to the alias cache.
In all steps after that within the same scenario, you can use this alias to refer to that specific record. This can be done in the steps themselves, in example: "When {alias} is updated with the following values" will retrieve the record from the alias and update it.
It can also be used in tables as value of a lookup field. If this is done, then the test will not query CRM, instead it uses the record found in the alias cache.
Whenever a new record is created, you can supply some default values so that you don't need to enter the same values every time you create a record. You do that by specifying the value in the DefaultData.xml file. See the example project for an example of that file.
Targets are specified via SpecFlow tags. When you setup your own project, make sure to include the Targets and the DeploymentTransformations from the Default.srprofile file in the sample project. The following tags are included by default: API, Chrome, Edge, Firefox and IE. These tags will specify the execution method.
Every step will execute 1 or more commands. There are 3 types of commands. Below is specified how they behave.
| Command | API Testing | UI Testing |
|---|---|---|
| APIOnlyCommand | Runs via API | Runs via API |
| BrowserCommand | Runs via API | Runs via UI |
| BrowserOnlyCommand | Exception | Runs via UI |
In steps that refer to arributes, you can use Display Names instead of logical names. This will make your test scenarios more readable. There are a couple of limitations and considerations.
First of all it will look at the display names of the language code that is specified in the app.config. It is also possible that an entity has multiple fields with the same display names, in that case you have to use the logical name. Finally it uses the display name of the field as configured on the entity customizations and not the custom label of the field on the form.
When working with DateTime fields in Dynamics, the SpecFlow project assumes the DateTime written in the SpecFlow features are written in the local time of the Dynamics User.
When you want to do negative testing, you don't want your test to fail on some exceptions. When you add the @ExpectedError tag to your scenario, then some exceptions will be ignored in your 'When' steps. Currently the 'Save Failed' exception will be ignored.
When using tables in specflow, you have the option to add formulas as the value of a field. To define a formula, start with the '=' character.
| Formula | Description |
|---|---|
| Now() | Current timestamp |
| Today() | Today's date at midnight |