Question

我一直在玩Specflow，通常使用页面对象模型设计。我已经开始将接口用作步骤定义中的步骤，然后在页面对象模型中实现这些接口。

到目前为止，这似乎工作得很好，我可以交换硒页面模型并针对API运行方案，而无需更改步骤定义。

例如

[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());
    }
}

我在任何地方都没有看到这样的示例，并且有点担心我完全错过了界面的要点，这将使我的生活变得非常困难，并且需要做很多重写工作。

所以我的问题是，这是使用接口的正确方法吗？这种方法是否有可能在以后引起我的麻烦？

谢谢

Answer 1

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

Answer 2

我想说，相对于接口而不是具体的类进行测试是一种相对好的做法。如果您认为按照测试的方式应该只测试与类的可公开访问的交互，那么对接口进行测试就很有意义。它还可以让您通过一个测试一次测试多个实现。

另一方面，只要您知道该类是同类中的唯一类，那么测试一个具体的类就没有什么害处，并且没有理由相信该类在不同情况下的实现可能有所不同，那为什么要麻烦界面呢？您只需针对类本身的公共API进行测试，就不会造成任何伤害！

尽管有最后一个陷阱，但这很可笑。如果您的类是另一个类的依赖项，那么为了测试另一个类，您必须使其成为一个接口，以便可用的模拟框架能够使用它。有“ Shimming”或“ Faking”框架，但它们相当简单。

总体而言，我将使用仅界面测试，这样可以避免您希望从一开始就做的麻烦。只要整理得井井有条，就可以使用多余的接口文件，这是值得的。

使用步骤定义和页面对象之间的接口进行Specflow

2 个答案: