One background for different features

[PBuchmann]

Just assume that we have one background that we define in a feature file.
Is it possible to use this background in different feature files? We find it usefull to be able to outsource a commonly used background into a specific background feature.
If not possible out of the box, how could I implement such a feature?

[ajeckmans]

It is not possible. Typically you'd use tags and hooks for such things.

Are we talking about a functional or non-functional background for the features?

[PBuchmann]

Our usage is different, but just assume that we have a website that needs a logon and we have a lot of features that need the same logon. Those features are distributed into severeal feature files and we search for a possibility to reuse the same logon background in all feature files instead of duplicating the code.

While using Specflow we had implemented a GIVEN statement that was able to call such a global background from a different feature. We were indeed able to call several backgrounds in a row. In Reqnroll we experienced problems in our old code for Specflow and realized that everything is async now and our call does not work anymore. We had following for Specflow:

private void CallFeatureBackground(string featureName)
{
    var type = AppDomain.CurrentDomain.GetAssemblies().SelectMany(x => x.GetTypes()).FirstOrDefault(x => x.Name == featureName);
    if (type == null)
    {
        type = AppDomain.CurrentDomain.GetAssemblies().SelectMany(x => x.GetTypes()).FirstOrDefault(x => x.Name.ToLowerInvariant() == featureName.ToLowerInvariant());
        string message = type == null ?
            $"The type {featureName} is not defined." :
            $"The type {featureName} is not defined, but the type {type.Name} exists. Please use the correct name.";
        throw new ArgumentException(message);
    }

    var featureSetup = type.GetMethod("FeatureSetup");
    _ = featureSetup.Invoke(null, new object[] { null });
    object feature = Activator.CreateInstance(type);
    var featureBackground = type.GetMethod("FeatureBackground");
    _ = featureBackground.Invoke(feature, new object[] { });
}

I've changed the lower part now to following:

var feature = Activator.CreateInstance(type);
var featureSetup = type.GetMethod("TestInitializeAsync");
var task = (System.Threading.Tasks.Task)featureSetup.Invoke(feature, new object[] { });
task.Wait();
var textContextProperty = type.GetProperty("TestContext");
textContextProperty.SetValue(feature, this.testContext);
var scenarioInitialize = type.GetMethod("ScenarioInitialize");
scenarioInitialize.Invoke(feature, new object[] { this.scenarioContext.ScenarioInfo });
var featureBackground = type.GetMethod("FeatureBackgroundAsync");
var task1 = (System.Threading.Tasks.Task)featureBackground.Invoke(feature, new object[] { });
task1.Wait();

This actually works but I have the problem, that the class that contains the test steps is created twice. In this class we currently have properties that get created by dependency injection. By creating the type twice, we now have problems in passing data from the background to the test.

• I see the possibility to move the properties into the scenarioContext resp. testContext. Would this be the correct way for the migration?
• Could I somehow prevent the second creation of the steps class?
• I understand that this request ist questionable, but if the feature files would implement an interface, it would overall be easier to make such calls and we wouldn't need to use reflection. I understand that you might reject the usage of an interface because it would enable usage scenarios that are not desired, but it would be usefull for our case.
• I assume that possibility to reuse a background in several features could be useful for other users. Maybe you could add such a feature to Reqnroll.

[PBuchmann]

I think I understand my problem a bit more now.

I've got a specific class that contains the binding that I use in the background. But this class contains more bindings than this one. In SpecFlow only one object of this class was instanciated. In Reqnroll it seems that each feature instanciates it's own instance of the class. So it seems that my problem is something like a life time issue of the objects that contain the bindings that are used within different features.

This is only an assumption as for now.

[PBuchmann]

OK. It's hacky as hell but works:

            var feature = Activator.CreateInstance(type);
            var fieldInfo = type.GetField("testRunner", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
            fieldInfo.SetValue(feature, this.testRunner);
            var textContextProperty = type.GetProperty("TestContext");
            textContextProperty.SetValue(feature, this.testContext);
            var scenarioInitialize = type.GetMethod("ScenarioInitialize");
            scenarioInitialize.Invoke(feature, new object[] { this.scenarioContext.ScenarioInfo });
            var featureBackground = type.GetMethod("FeatureBackgroundAsync");
            var task1 = (System.Threading.Tasks.Task)featureBackground.Invoke(feature, new object[] { });
            task1.Wait();

My problem was that by calling the method TestInitializeAsync a new TestRunner instance was created and stored in the field testRunner. I had to pass the existing TestRunner of the already running test.

[ajeckmans]

It is a creative solution. I'd urge you to look into bindings and tags though as that is a stable solution, whereas this could change at any moment.

[PBuchmann]

This hack existed since ages and we simply wanted to migrate to reqnroll. There's always room for improvements.
Thank you for your hints.