Specflow using interfaces between step definitions and page objects

Question

I've been playing with Specflow, and generally use a page object model design. I've started to use interfaces as the step in the step definitions, then implementing the these interfaces in the page object models.

So far this seems to be working quite well, and I can swap out the selenium page models and run the scenarios against API's instead without having the change the step definitions.

eg

[Binding]
public class SearchByClaimSteps
{
    ISearch Search = new Page_Object_Models.SearchPage();
    IClaimDetails ClaimDetails = new Page_Object_Models.ClaimsDetails();

    [When(@"I search by claim number using '(.*)'")]
    public void WhenISearchByClaimNumberUsing(string claimNumber)
    {
        Search.ByClaim();
        Search.ClaimSection.EnterClaimNumber(claimNumber);
        Search.ClaimSection.StartSearch();
    }

    [Then(@"the claim will be found")]
    public void ThenTheClaimWillBeFound()
    {
        Assert.Equals("Condition Declined", 
        ClaimDeatils.GetConditionStatus());
    }
}

I haven't seen an example of this anywhere, and am a bit worried I have missed the point of interfaces completely and am about to make my life very difficult and will have a lot of re-writing to do.

So I my question is, is this a correct way of using an interface, and is there a potential for this approach to cause me problems later on down the line?

Thanks

Answer 1

您是否检查过Gaspar Nagy的这篇帖子-它涵盖了上下文注入和DI的所有基础-http: //gasparnagy.com/2017/02/specflow-tips-baseclass-or-context-injection/ ？

Answer 2

I'd say it's a relatively good practice to be testing against interfaces instead of concrete classes. If you think along the lines of your tests should only be testing the publicly accessible interactions with your class anyway, so testing against an interface makes total sense. It would also allow you to test multiple implementations at once with a single test.

On the flip-side, there's no harm in testing a concrete class, as long as you know that class is the only one of its kind, and there's no reason to believe that the class may have differing implementation in different scenarios, then why bother having the interface? You could just test against the public API of the class itself, no harm done!

There's one last gotcha though, and that's mocking. If your class is a dependency of another class, then in order to test the other class you'll have to make it an interface so that the mocking frameworks available will be able to work with it. There are "Shimming" or "Faking" frameworks, but they're fairly naff.

Overall, I'd go with interface only tests, saving you the pain for when you wish you'd done it from the beginning. The extra interface files you'll have kicking around are worth it, just keep it organised.