单元测试添加/获取方法对

Question

我是一名用C#编写的.Net开发人员,我被分配到一个项目,其经理希望它经过彻底的单元测试,主要是强调隔离,这样一个逻辑错误理想地失败了一个测试,并且测试之间没有依赖关系.

今天我们正在讨论测试模式,并出现了以下问题:

假设我们有一个名为的对象MyHashTable,它实现了:

void Add(string key, string value);

string GetValue(string key);

我们想要独立地测试每个方法.当然,主要的问题是,从逻辑上讲,我们无法获得我们从未添加过的内容,而且我们无法在没有获取的情况下验证添加的内容.我们已经听过并读过关于存根/模拟和其他可能有助于克服这些问题的技术,但无法确定哪种解决方案最具可读性和可维护性.

因此,我要求提供建议/想法如何单独测试这些方法,如果可以,请为您的建议包含优缺点.谢谢!

Answer 1

如果您想实现完全独立和隔离，那么您很可能必须公开MyHashTable. 例如，Add将元素添加到的底层集合：

public class MyHashTable<TKey, TValue>
{
    internal Dictionary<TKey, TValue> Storage { get; set; }
    // ...
}

正如您所看到的，这并不是很漂亮，但就像我说的那样，不可能在不暴露某些内容的情况下完全隔离地测试这两种方法（就像您注意到的那样，它是一个方法对）。您自然可以提供其他方法来初始化您的类，例如。构造函数接受集合，但它只是将问题进一步委托 - 您需要验证构造函数是否也有效，并且您可能需要Get为此的方法...这会让您回到原来的问题。

编辑：

请注意，我并不是建议将揭示内部/实现细节作为唯一的途径。您可以简单地一起测试这些方法（不像单个测试，而是一种方法利用另一种方法），这可能被证明是更好的解决方案。当然 - 如果你Add在某个时候失败了，Get测试也会失败。但话又说回来，你想要修复损坏的部分Add——一旦完成，一切都会恢复正常。问题自然在于如何区分它是否Add被Get破坏 - 但这就是我在评论中链接的正确断言失败消息或保护断言概念派上用场的地方。

事实是，有时完全分离和隔离太难实现，或者只需要引入糟糕的设计。这就是他们永远不应该成为最终目标的原因之一。