-
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 |
You can overrule the above behavior by using a tag on your tests. It's technically possible to add multiple of these tags, however doing so will create unpredicatable results.
| Command | ForceAPI | PreferApi | ForceBrowser | PreferBrowser |
|---|---|---|---|---|
| APIOnlyCommand | Runs via API | Runs via API | Exception | Runs via API |
| BrowserCommand | Exception | Runs via API | Runs via Browser | Runs via Browser |
| BrowserOnlyCommand | Exception | Runs via UI | Runs via Browser | Runs via Browser |
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.
As stated above you can specify a langage code in the app.config to state the input langauge of SpecFlow. You should put the base language there of your environment. If you put any languagecode there that isn't the base language, you will need to make sure that everything that you test has a translation.
Aside from the input language you use in features, your user may have a different UI language. The framework checks the user settings of the user to find the UI language and will translate labels, option sets etc. to the UI language of the user. In this case it will fall back to the language in the app.config if there is no translation for that particular item.
There are some aspects that need to be localized that isn't available in the metadata. For that part a JSON file is used. The sample contains the dutch translations. Add it to your feature project and set it to copy always. All English defaults can be found here. If you want to use any non-english language, either as base language or UI language, you need update the json file for your language and translate all items. You specify the relative path to the JSON file in the app.config
Easiest way to is to copy the json file from the sample file, remove the items specific to the sample project, the whole 1033 section and start from there with your own language. All items in the 1043 section above the comment regarding the sample specific messages are the ones you need to translate.
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. You need to have added the 'Vermaat.Crm.Specflow.Expressions' nuget package for this to work.
| Formula | Description |
|---|---|
| Today() | Today's date at midnight |