Inheriting the Specflow test step calls up "Undefined step definitions",

Question

I want to have the following test step class structure:

[Binding] public class BaseStep { [Given(@"there is a customer")] public void GivenThereIsACustomer(Table table) { HandleCustomer(table); } protected virtual void HandleCustomer(Table table) { } } [Binding] public class FeatureOneStep : BaseStep { protected override void HandleCustomer(Table table) { // feature one action } [Given(@"feature one specific step")] public void GivenFeatureOneSpecificAction(Table table) { // do something } } [Binding] public class FeatureTwoStep : BaseStep { protected override void HandleCustomer(Table table) { // feature two action } [Given(@"feature two specific step")] public void GivenFeatureTwoSpecificAction(Table table) { // do something } } 

“Given that there is a client” is a general step that is used both in FeatureOne and FeatureTwo, but it will have different processing logic inside two functions. Therefore, I decided to include the definition of this step in the base class and override the protected methods in the two derived classes, respectively.

However, when I ran the tests, I had the following error:

 TechTalk.SpecFlow.BindingException: Ambiguous step definitions found for step 'Given there is a customer': CustomerTestBase.GivenThereIsACustomer(Table), CustomerTestBase.GivenThereIsACustomer(Table) 

Can someone tell me how to fix this problem?

Answer 1

Just think about it now, so a few notes (hope someone can use this in the future):

• Do not include the [Binding] attribute in the base class
• Create a derived class for each function file.
  • Add the [Binding] attribute to the derived class (will automatically include all step definitions in the base class)
  • Add the [Scope] attribute to the derived class; provide a function name for the named parameter. Function

Answer 2

The answer is simple; Do not use inheritance to define your bindings.

At run time, SpecFlow finds its methods to be called by global scanning in all public classes looking for methods with matching [Given] attributes. This means that you cannot have two different implementations for the same operator Given there is a customer , which, if you think about it, is a pretty reasonable design solution that will reduce ambiguity.