2

Endeca 的大部分或全部对象都有内部构造函数。我正在开发一个缺乏对 Endeca API 很好的测试覆盖率的好项目，是否有任何好的策略来单元测试与 Endeca 的交互？

到目前为止，我们拥有的最好的是一种穷人的适配器模式：

public class DimValue : IDimValue
{
    public DimValue(Dimension dim, DimVal dimValue)
    {
        Dimension = dim;
        Value = dimValue;
    }

    public virtual bool IsNavigable()
    {
        return Value.IsNavigable();
    }

    public virtual long Id()
    {
        return Value.Id;
    }

    // and so on...
}

然后我们可以模拟我们自己的类型 DimValue。这是保持 API 尽可能可测试的最佳方式吗？还是有另一种方法比这更受欢迎？

4

2 回答 2

1

如果您正在尝试测试 API 的使用情况，那么我会推荐您提到的方法。

编写基于您自己的抽象而不是其他人的抽象的应用程序是一个很好的设计目标。适配器层让您有机会将 API 翻译成您的开发人员更熟悉的领域语言，并且如果您使用的产品在某些方面存在不足，您可以在以后更改技术。

Resharper 有一个很棒的功能来创建包装类。创建一个类，添加一个要包装的类型的成员..然后触发生成委托重构。选择“全部公开”，然后就可以了……一堂包装课。

仅公开您实际使用的功能子集。在您的包装代码中，提供接口以便您可以模拟。

如果您将 Endeca 的 API 测试为某种形式的回归套件，以便您可以更轻松地接受他们新发布的 API，那么我只会在更“接受”级别编写测试；练习他们给你的 API。但同样，只测试您实际使用他们的 API 的方式。

我会做上述方法，但是......

TypeMock 将允许您模拟没有接口的类，因此可能允许另一种方法。

希望这可以帮助。

于 2010-10-07T21:33:30.353 回答
0

大多数 Endeca 类都是具体的，因此很难进行单元测试，在我们上一个项目中，我们必须为自己定义一个抽象层，它恰好是我们自己的代码和 Endeca API（例如 IEndecaQuery）之间的一个外观层。有了这个抽象层，我们可以在没有任何真正的 Endeca 访问的情况下快速进行测试，您知道每次打开 Endeca 连接将花费您几秒钟的时间。实现所有必要的 Endeca 假对象需要做很多工作。我们的应用程序是一个电子商务网站，我们将 Endeca 用于所有产品列表、搜索功能。

于 2010-10-08T04:33:12.510 回答