I have a test framework written in C#, I am using Selenium, nUnit and Specflow.

Visual Studio is the tool and I have the normal project folder structure (pages, hooks, steps, features).

Testcases are associated with AzureDevOps and the code is pushed to the repo and pipilines are working great.

My issue is that I want to hide the code under the level of the features.

The idea is that other people could create new feature files and create tests within them, but I do not want them to be able to see the code that is under those Gherkin sentences.

So they should be only able to create and write new features, but not seeing the code below.

Could you please give me some ideas how this can be achieved?

CodePudding user response：

You can import bindings from external assemblies. In SpecFlow.json, add:

{
  "stepAssemblies": [
    {
      "assembly": "Name.Of.Your.StepDefinitions.dll"
    }
  ]
}

While this is typically used as a means to reuse step definitions in multiple projects, you could use this to "hide" the step definitions from test writers. The step definitions would be a pre-compiled DLL file that they can import into a different Visual Studio solution.

This requires two different solutions in Visual Studio:

1. A regular class library that holds step definition classes. You will probably need to choose .NET Core or .NET Framework 5 , since it must integrate with a unit testing framework. I don't believe .NET Standard would work (but you can certainly try).

2. Another Visual Studio solution that testers can use, which contains the feature files. This project would reference a DLL file you would create from project #1.

The challenge is disseminating this DLL file. Any update you make would need to be given to the testers' Visual Studio solution. A couple of options come to mind:

1. Manually update solution #2.

2. Create a NuGet package for solution #1. Set up a build pipeline in Azure DevOps to build, package, and push this NuGet package to your project's "Artifacts" feed whenever you make code changes. Someone (you or a tester) would need to update that NuGet package in solution #2.

As an alternative, give everyone access to the features and step definitions, but enforce a pull request policy on the repository requiring you as a reviewer. That way you can protect the main branch as the gatekeeper. Testers can submit changes to step definitions, and you are free to reject their pull requests if the changes are not satisfactory.

This, of course, depends on the team structure. If you have outside contractors, sharing the step definition code might not be desirable. Just don't limit people's abilities simply because you don't trust their skill level. Use pull request policies requiring you as a reviewer if they change step definition files. This allows you to benefit from someone else's labor while still giving you control.