SpecFlow.Rider
SpecFlow.Rider copied to clipboard
Steps not being found when inheriting scope and binding attributes.
I have a simple base class for my integration tests that is decorated with the relevant binding and scope attributes.
[Binding]
[Scope(Tag = "Integration")]
public abstract class IntegrationTestBase
{
protected readonly ScenarioContextHelper Helper;
protected IntegrationTestBase(ScenarioContextHelper helper)
{
Helper = helper;
}
}
All of my integration test classes inherit from this and my tests run absolutely fine.
However, these steps are not found by the plugin so I get warning squigglies in my feature files and keyboard shortcuts don't work.
Currently base classes are not supported when looking for the Binding attributes, we are investigating the possibilities how we can improve this in the future.
Any plans for this? It's really annoying..
@nemesv is this still being looked into? Just wondering as being able to have base steps and inheritance is great, but the loss of any form of highlighting etc is just such a killer.
Hello, I would like to have more info about the problem here, is it only to avoid putting [Binding] on the child class or is there more to it ? Could you provide a small repro ?
@Socolin
[Binding]
public sealed class CalculatorStepDefinitions : StepDefinitionsInherit
{
// For additional details on SpecFlow step definitions see https://go.specflow.org/doc-stepdef
[Given("the first number is (.*)")]
public void GivenTheFirstNumberIs(int number)
{
//TODO: implement arrange (precondition) logic
// For storing and retrieving scenario-specific data see https://go.specflow.org/doc-sharingdata
// To use the multiline text or the table argument of the scenario,
// additional string/Table parameters can be defined on the step definition
// method.
throw new PendingStepException();
}
[Then("the result should be (.*)")]
public void ThenTheResultShouldBe(int result)
{
//TODO: implement assert (verification) logic
throw new PendingStepException();
}
}
//[Binding]
public abstract class StepDefinitionsInherit
{
[Given("the second number is (.*)")]
public void GivenTheSecondNumberIs(int number)
{
//TODO: implement arrange (precondition) logic
throw new PendingStepException();
}
[When("the two numbers are added")]
public void WhenTheTwoNumbersAreAdded()
{
//TODO: implement act (action) logic
throw new PendingStepException();
}
}
Use the two classes above, in Visual Studio
"And the second number is 70"
Will correctly pick up the inherited step definition without needing the Binding attribute on the second class, the Rider extension however doesnt pick up the step definition as its from an inherited class.
If we uncommented the Binding, we get an error though - even though the second class is abstract so cant be instantiated, with the Binding attribute, specflow throws an error as it now has "ambiguous step definition" and points to have two definitions that both exist in the StepDefinitionsInherit class. However, by having the Binding the rider extension does pick up the step defition correctly, though the tests are unable to run. The Visual Studio version, with binding on the base class will highlight an error in the feature file if the base class has binding attribute on it.
The reason this is a problem, is because - if I pass in something like a Scenario, and pass that down through the inherited classes, its all great - if I stop using inheritance, and put binding on everything, the Scenario that gets passed into each step file is unique so I lose access to any data between steps which we cant do. But, we cant put binding on the child classes or it causes ambiguous step definition errors
What happen if 2 class implements the StepDefinitionsInherit ? (I suppose it's where the Scope attribute is useful but I would like a confirmation)
I added support for [Scope] I'll check the inheritance next
What happen if 2 class implements the
StepDefinitionsInherit? (I suppose it's where theScopeattribute is useful but I would like a confirmation)
Yes, it is using Scope in the final class of the chain. Each feature file has a Step file scoped specifically to it, and that can then inherit from common shared steps
Thanks for the details, should be fixed in the next release, you can already test this with this build https://github.com/SpecFlowOSS/SpecFlow.Rider/actions/runs/7005615857
I no longer use SpecFlow, but it's nice to see this get sorted, good work!