假设我们正在使用 TDD 实现一个 Stack 类，我们需要为 Stack 类的每一位功能添加一个新测试来执行它:
[TestMethod] public void Should_Be_Empty_After_Instantiation()
[TestMethod] public void Should_Not_Be_Empty_After_Pushing_One_Item()
...
现在，另一方面，在进行单元测试时，应该关注我们的类应该提供什么样的外部行为，因此单元测试集会检查我的 Stack 接口(interface)的所有预期契约是否得到满足。
我的问题是如何调和这两个方面。
例如，假设我的 Stack 在内部使用一个初始大小为 8 的数组，如果我的用户想要插入第 9 个项目，我希望它增长。为了添加调整大小的功能，我希望至少有一个测试可以在那个方向上驱动我的类代码(我说的对吗？)。
另一方面，这将添加一个单元测试(或者这不是一个真正的单元测试？)，它不执行类的实际契约(Contract)(我假设用户不关心Stack 的内部实现)但它的实现。
所以我们这里有一个问题，我不知道如何解决。我在这里混淆了概念吗？
谢谢
编辑
经过多次谷歌搜索后，我找到了以下似乎可以解决此问题的链接: http://stephenwalther.com/blog/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx
最佳答案
您可以编写一个测试，将第九个项目压入堆栈。如果您没有任何调整大小的逻辑，那显然会失败。但是，将 9 硬编码到测试中似乎不是一个好主意，因为您会将 Stack 的内部实现细节合并到测试中。
现在，TDD 测试的编写通常会告知作者他的 API 中可能存在的漏洞。在这种情况下，测试希望能够指定 Stack 的初始预分配大小。然后它可以将其设置为 8 或 2 或其他值，然后再推送一项。而且，认为其他客户可能也需要它并非不切实际(例如，它类似于 std::vector 的保留方法)。因此，我会考虑向 Stack 添加一个构造函数参数以指定初始保留大小，将其默认为 8，并添加一个 Should_Not_Error_When_Pushing_More_Items_Than_Initial_Size 测试。
关于unit-testing - 如何协调 TDD 与 SUT 接口(interface)的合约？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3604142/