Pulling Test Case changes to local scenarios

In the majority of the cases, the scenarios are changed in the feature files. This ensures that all necessary automation infrastructure (eg. step definitions) are also adapted when a change has been performed in the scenario.

In some special cases, it might be useful to be able to make small changes in the Test Cases synchronized from the scenarios directly in Jira. Synchronizing such changes back to the feature files is a complex process and it is only recommended if it's really required.

SpecSync provides a feature for two-way synchronization using the pull command.

In order to use the two-way synchronization feature efficiently, we recommend having a team agreement about whether the feature file or the Jira Test Case is the primary source of information at a time. For example, in the sprint planning preparation phase, the changes are made in the Jira Test Case, but once the sprint has been started, the changes are made in the feature file first.

The pull command (two-way synchronization) is an Enterprise feature.

Two-way synchronization workflow

In order to be able to use two-way synchronization, it has to be enabled in the SpecSync configuration file in the synchronization/pull section:

{
  ...
  "synchronization": {
    ...
    "pull": {
      "enabled": true
    },
    ...
  },
  ...
}

Once this configuration has been done, the general workflow could be:

1. Make sure the project compiles, tests pass and the modified files are checked in to source control.

2. Pull Test Case changes from Jira:

   dotnet specsync pull

3. During the pull operation SpecSync might ask you to help resolving conflicting changes.

4. Verify if the changes are correct (compiles, correct Gherkin syntax, steps are defined, etc.)

5. Push back to Jira (we recommend this step even if there were no fixes required, because this way SpecSync can register the current state of the scenarios in Jira)

   dotnet specsync push

6. Check in (commit and push) your changes to source control

SpecSync cannot ensure that the updated feature files are committed to the source control. If these changes are not committed, and someone else is also performing the synchronization, the changes will be synchronized multiple times causing various conflicts. We recommend to ensure that there are no parallel pull operations are performed.

In certain cases SpecSync is not able to restore feature-level Gherkin constructs (e.g. feature-level tags or "Background" steps) without changing the behavior of the other scenarios in the same feature file. In this cases the pull command will finish with a warning and you need to review the performed changes manually.

SpecSync operations, including the pull command supports "dry-run" mode using the --dryRun command line option. In dry-run mode, no change is made neither to Jira nor to the feature files, so you can test the impact of an operation without making an actual change.

Pulling links

If the Test Cases you pull from contain issue links, SpecSync will try to create issues link tags from them.

SpecSync attempts to use the best tag prefix if there are multiple available by selecting the first with matching targetType or the first of the ones without targetType otherwise. For the best experience for pull, it is recommended to avoid prefixes with the same targetType or having multiple link prefix without targetType.

If a issue link is removed from the Test Case, the pull operation will remove the corresponding link tag from the local tets case.

Creating new scenarios from Test Cases

This feature is planned for a future version of SpecSync for Jira. Please check the Roadmap for details.