关于单元测试的几个问题

Question

假设我们正在设计一个测试优先 (TDD) 的 Stack 类：

public class Stack<T> {
    private T[] elements = new T[16];
    private int size = 0;
    ...
}

该 Stack 使用大小为 16 的内部数组来存储其元素。它会正常工作，直到您需要添加第 17 个元素。由于我可能需要第 17 个元素，因此我决定将该功能添加到我的堆栈中，因此我开始考虑可以为必须添加该功能的测试起什么名称。这将是我第一个问题的主题。

我首先选择了以下形式的内容：

Should_Be_Able_To_Correctly_Increase_Its_Inner_Array_Size()

然后，

Should_Handle_More_Items_Than_The_Default_Internal_Array_Size()

经过一番思考，我得出的结论是，也许像下面这样的内容会更合适：

Should_Double_Its_Size_Every_Time_Its_Full()

在第一种情况下，我的推理必须这样做，我只是说了什么确实如此，但不知道何时。 在第二个中，我说的是何时添加更多项目，但我也说明了我如何考虑实现它（内部），这可能不正确。在我看来（我不确定我是否正确），我的测试应该是我的 SUT 与外部可能的交互，而不是它的内部实现方式。我说得对吗？

在我看来，第三个选项是最好的，因为它清楚地说明了它的作用（尺寸增加 - 事实上，尺寸增加了一倍）、何时（当它满了）并且不会将我与任何特定的东西联系起来实现（我可能稍后想将其更改为内部 ArrayList！）。

这引出了我的第二个问题：假设我对内部使用数组的 Stack 类进行了所有单元测试，并且它工作正常且符合预期，如果我以后想要，我的测试是否应该保持不变重构并将数组更改为 ArrayList 或任何其他类型的数据结构？或者测试是否应该以某种方式反映这一点？我猜不会，但我不确定。

Answer 1

在我看来（我不确定我是
正确），我的测试应该是可能的
我的 SUT 与
外观，而不是它的样子
内部实施。我说得对吗？

你是对的。如果更改类的内部实现，单元测试应保持不变。如果您向外部公开任何新内容，则应该创建新的单元测试来解释这些更改。

请记住，当您设计类时，您不想暴露任何表明其实现方式的内容。类的公共成员指示如何与其交互，现在它是如何在幕后工作的。

Answer 2

我不确定如何通过单元测试来测试内部列表或数组大小。您无法通过 Stack 接口访问它。单元测试用于测试外部合约。如果您想测试实现细节，请尝试其他方法。

第二个问题的答案是肯定的，如果是单元测试，测试仍然应该通过。

Answer 3

问问自己你愿意为这门课做出什么承诺。

你或班级的消费者真的关心容量是加倍、增加一倍还是增加一千吗？如果是这样，您应该修改接口，以便他们可以指定用于增加容量的策略：

public Stack<T>(CapacityGrowthStyle capacityGrowthStyle) { ... }

如果不是，只需编写测试来记录容量并保留它（其中下面的 X 是您的基础数据结构的限制）：

[Test]
public void Can_Handle_X_Items() { ... }

[Test]
[ExpectedException(typeof(InvalidOperationException))]
public void Cannot_Handle_More_Than_X_Items() { ... }

我会类似地回答你的第二个问题：如果你的类的用户关心它，你的测试应该只反映底层数据结构。

Answer 4

我不确定您是否应该通过单元测试来测试内部列表或数组大小，因为您无法通过 Stack 接口访问它。实现堆栈的方法有很多，有好有坏，但正如伯纳德所说，这些都是内部实现。单元测试旨在测试面向外部的功能。