Dear SpecSync Users,
Just before Christmas we released v3.4 of SpecSync for Azure DevOps, which has been one of the most exciting releases in the history of SpecSync since 2016.
There are a couple of useful new features in this release that I am describing below, but the thing that makes this release special is that this is the first major release we did since the initial introduction of SpecSync for Jira. As an Azure DevOps user probably you won’t find it very interesting that SpecSync is now available for Jira as well, but in a way it might be. SpecSync for Azure DevOps and SpecSync for Jira are now built on the same code-base; it means that many improvements made for SpecSync for Jira are also available for the Azure DevOps product. From this version on, this is true for SpecSync plugins as well. If someone makes a plugin for SpecSync for Jira, it will work for SpecSync for Azure DevOps as well.
I will highlight a couple of useful new features in this email, but as always you can take a look at the complete changelog. As this is a major release, there are a couple of breaking changes. Make sure you scan them through before upgrading, although most of them are minor ones or affect only users of specific features. In a couple of cases we needed to consolidate the configuration structure, so some settings have been renamed or moved. The full list you can find in the deprecation notices. The old settings are still available but using them causes a warning. Fixing these should be just a matter of minutes.
But now, let’s have a look at the most exciting features.
More flexibility with updating Test Case fields: Conditional field updates
Our Enterprise edition users could use the “Custom field updates” customization for a while now. That customization was useful if you had to update Test Case fields that SpecSync does not update automatically. The customization had a limitation though: you could not update the fields based on the scenario tags. So for example if your team used tags, like @priority=high and @priority=low, you could not update the “Priority” field based on that, because the value expression could not depend on the tags of the scenario.
The new feature enables field updates in a much more flexible way! You can decide when the update should happen (e.g. only if the Test Case is created), you can setup complex conditions of tags and file path conditions to control when to update the fields, you can use the parts of the tag text as value and you can even implement “switch-case” like constructs to set a field to different values.
The good news is that unlike the customizations, this feature is available for updating default Test Case fields also for Free and Standard edition users. Updating custom or non-default fields requires Enterprise license.
The feature documentation contains a detailed description of all the possibilities with a bunch of different examples that help you with the usage. The example below shows a way how the example with the priority above can be achieved with the new feature:
{
…
“synchronization”: {
“fieldUpdates”: {
“Priority”: {
“condition”: “@priority=*” // * matches to anything after “@priority=” here
“value”: “{1}” // {1} refers to the *-part of the tag, i.e. “high” or “low”
}
}
}
…
}
Filter based on source file path: Source file path conditions
In many places in the configuration file you can use conditions, for example when you specify automation details but also in the new field updates feature we just mentioned. Those conditions can traditionally contain tag expressions. With the new release, you can also use source file path expressions as well in the conditions. So for example the following expression selects all scenarios that are tagged with @important, but only within the “pricing” folder: “@important and $sourceFile~pricing/”. Again, you can find more details in the feature description.
Load plugins from NuGet feed
We introduced the concept of SpecSync plugins in v3.1. These plugins became useful tools for implementing special requirements of some organizations, but a couple of open-source plugins has been published on GitHub as well.
Using plugins was a bit cumbersome because you had to share the plugin binary files with the other team members. In the new release now it is possible to load plugins from a NuGet feed and the open-source plugins have now been published to nuget.org as well, so you can try them out or use them without needing to compile the plugin.
The documentation now contains a list of ready-to-use plugins. With these plugins you can synchronize test cases from non-Gherkin sources, like an Excel file or an MsTest unit test, or you can implement special synchronization models, like synchronizing scenario outlines to a non-parametrized test case.
Loading plugins from public external sources always introduces security concerns. This is not a problem if you load the plugins from your local NuGet feed or from a local or shared folder in your organization, but if you load the plugins from nuget.org, you have to be careful. To address that, you always have to specify the exact version of the plugin you want to use. In addition to that, the plugins published by us (Spec Solutions) are signed with or code-signing certificate. These plugins are covered by our support and can be used with SpecSync without additional approval. Any other plugins, however, can only be used if you approve downloading 3rd party plugins in the configuration.
In this first version, we only support unauthenticated feeds (feeds where you don’t need any user name and password to download packages), but later we will extend the feature for authenticated sources as well. Your feedback is welcome.
Other useful improvements
As mentioned, there are a couple of other useful improvements as well, for example the support for .NET 7, SpecFlow 4 or the Cucumber Java Surefire XML report. The “pull” command now also supports back-synching work item links (it creates or removes link tags accordingly) and you can override the default tag separator (:) in order to use tags like @TestCase=123 (instead of the default @tc:123).
Next steps
With the v3.4 release out, we will not stop making improvements. This release has also been a preparation for the next big thing: synchronizing test suite hierarchies. Many teams using SpecSync would need to build up a more complex suite hierarchy. This can be achieved with query-based suites, but a direct support for maintaining these hierarchies by SpecSync would be useful. As easy this feature sounds as complex it could get if you think about the details of how the hierarchy should be built up (by folders, by tags or something else) and who is responsible in removing Test Cases from the suites. This becomes even more tricky if you want to use the suites to hold other Test Cases as well.
So the next step of the preparation will be a survey that I would like to use to collect information from you about how you would use this feature. There will be a separate email about that, please stay tuned.