The big point here is that Step Binding
s are global.
This seems to be a common anti-pattern with Specflow that lots of people goes through. Initially you have a phase of creating hierarchies of binding classes that match your feature files. Instead you need to create collaborating classes that don't match the features but instead produce features through their collaboration.
It's just like your main application code. You wouldn't have a single ATMMachineCashWithdrawal
class, instead you would have an ATMMachine
, that has a PINCodeCheck
, an OperationSelection
and a WithdrawalOperation
. Those objects collaborate to make your "I want to withdraw cash" feature, and when you add a "Check my balance" feature, you can reuse everything except the WithdrawalOperation
.
The bindings in Specflow are the same. We might have an ATMTester
that knows how to setup an ATMMachine
and supplies your Given I have a cash machine full of cash
and you could have a CustomerTester
that knows how to fake/mock/setup your account balance with Given my account has loads of money in it
.
Fortunately SpecFlow provides ways to collaborate the classes too. Have a look at http://www.specflow.org/documentation/Sharing-Data-between-Bindings/