How to define the local feature-set to be synchronized
Last updated
Was this helpful?
Last updated
Was this helpful?
When synchronizing the scenarios from a local repository you can define different set of scenarios to be synchronized. Maybe you want to synchronize all scenarios within the repository in one batch but maybe you need to have separate synchronization rules for the frontend and the backend scenarios.
The feature-set to be synchronized is called the local scope in SpecSync and can be specified using the . You can learn about local and and the difference between scopes and filers in the guide .
In this guide you will find the most common scenarios and the necessary steps to do this.
If you want to synchronize all scenarios from a folder (e.g. the features folder of your local repository), the easiest solution is to place your SpecSync configuration file into that folder. As the default settings of the local scope configuration take all feature files from a folder (and its sub-folders), you don't even have to specify anything in the local configuration.
The default local scope configuration in this case is equivalent to this settings:
If for some reason you don't want to put the configuration file into the folder of your feature files, you can set the folder to be used explicitly using the local/featureFileSource/folder setting.
In the following example, the specsync.json configuration file is in the local repository root folder, but the feature files are in the src/features folder.
Although modern .NET projects include automatically all files within the project folder you can explicitly exclude some files with a .NET project. If you want to synchronize those feature files that are included in the .NET project, you simply have to put the specsync.json configuration file to the project root folder and do not specify anything as local/featureFileSource.
Alternatively you can specify the project file explicitly:
Regardless whether you have used the folder-based or the .NET project based approach, you can further limit the scenarios or the feature files to be applied.
You can limit the synchronized scenarios to the ones match to a tag expression (e.g. everything tagged with @important) or you can specify a set of feature file paths globs, that should be included (e.g. **/Important*.feature). You can even combine these two options.
If the local repository contains multiple sets of feature files that need to be synchronized separately (e.g. frontend and backend related scenarios), you can create multiple SpecSync configuration files for each of them.
For organizing the configuration files for this setup, you have two main options to choose from: the configuration per folder and the different configuration files in root option. These options are shown in the sections below.
Let's imagine the following local repository structure
In this setup, there is a SpecSync configuration file in the src folder, that contains all common settings (e.g. repository URL), but this is not used directly for synchronization. For example:
The specsync.json files in src/backend/features and src/frontend/features contain all the frontend and backend specific details (e.g. the Test Suite to be synchronize the scenarios to). For example the one in the backend would look like:
If the synchronization is performed from the specific features folder, SpecSync will automatically use the specific configuration file and also automatically load the specsync.json file as well from the src folder, because all parent folders are searched for configuration files.
You can also invoke the synchronization from another folder, but in this case you need to specify the path to the configuration file.
For this option, let's imagine a folder structure, like this:
With this approach all configuration files are stored in a root folder (in the src folder in our case).
The specsync-parent.json contains the common settings (e.g. repository URL). You can find an example for the file content in the previous section where we discussed the configuration per folder option.
The specsync-backend.json and the specsync-frontend.json files contain the settings specific to the different feature-sets, but since they are placed in the root folder now, they need to have the necessary settings to configure the local scope and also the parent configuration file. The specsync-backend.json configuration file can look like this:
The synchronization for the frontend or the backend can be invoked by specifying the configuration file:
The different configuration files in root option that was shown in the previous section can also be used if the feature files are all in the same folder, and the scenarios are only separated by tags or file name conventions.
Let's imagine the following folder structure:
The scenarios in the backend_feature_b.feature are all tagged with @backend, the scenarios in frontend_feature_c.feature with @frontend and the ones in common_features_a.feature are tagged with both @frontend and @backend.
The specsync-parent.json contains the common settings and looks similar to the ones in the previous sections, but here we can even specify the main target folder:
The specsync-backend.json and the specsync-frontend.json files contain the settings specific to the different feature-sets by specifying the local scope using tags. The specsync-backend.json configuration file can look like this:
The synchronization for the frontend or the backend can be invoked by specifying the configuration file:
These settings can be configured with the local/tags and the local/sourceFiles settings. You can read more information about these options in the page.
In many cases some of the configuration options are common for the multiple feature-sets that you don't want to maintain separately in the configuration files of the particular feature sets. For this you can use the and specify the common settings in a parent configuration file.
The different configuration files in root option can also be used if the feature files are all in the same folder, and the scenarios are only separated by tags or file name conventions. This approach is shown in the section below.
Instead of the local/tags you could also separate the scenarios by file name patterns using the local/sourceFiles setting. You can find more information about this in the page.