如何协调 TDD 与 SUT 接口的合同? [英] How to conciliate TDD with SUT interface's contracts?

查看:26
本文介绍了如何协调 TDD 与 SUT 接口的合同?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

假设我们正在使用 TDD 实现一个 Stack 类,我们需要为 Stack 类的每一位功能添加一个新的测试来练习它:

Assuming we are implementing using TDD a Stack class, we would need, for each bit of functionality of our Stack class, to add a new test that exercises it:

[TestMethod] public void Should_Be_Empty_After_Instantiation()
[TestMethod] public void Should_Not_Be_Empty_After_Pushing_One_Item()
...

现在,另一方面,在进行单元测试时,应该关注我们的类应该提供什么外部行为,因此单元测试集检查我的 Stack 接口的所有预期合同是否都得到了满足.

Now, on the other hand, when doing Unit-Tests, one should focus on what external behaviour our class is supposed to provide, so the set of Unit-Tests check that all the expected contracts for my Stack interface are fulfilled.

我的问题是如何协调这两个方面.

My question is in how to conciliate those two aspects.

例如,假设我的 Stack 在内部使用一个初始大小为 8 的数组,如果我的用户想要插入第 9 个项目,我会希望它增长.为了添加调整大小的功能,我希望至少有一个测试来推动我的类代码朝那个方向发展(我说得对吗?).

For example, assuming my Stack uses internally an array with an initial size of 8, I'll want it to grow if my user wants to insert a 9th item. For adding that resizing functionality, I'll want to have at least one test that drives my class code in that direction (am I right?).

另一方面,这将添加一个单元测试(或者这真的不是一个单元测试?),它不执行类的实际合同(我假设用户不关心堆栈的内部实现)但它的实现.

On the other hand, that would be adding a Unit-Test (or isn't this really a Unit-Test?) that exercises not the actual contract of the class(I am assuming the user doesn't care for the internal implementation of the Stack) but its implementation.

所以我们在这里有一个转折,我不知道如何解决.我在这里混淆了概念吗?

So we have a twist here, that I don't know how to solve. Am I making any confusion of concepts here?

谢谢

经过多次谷歌搜索后,我来到了以下似乎处理这个问题的链接:http://stephenwalther.com/blog/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx

After much googling I came to the following link that seems to deal with this issue: http://stephenwalther.com/blog/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx

推荐答案

您可以编写一个测试,将第九个项目压入堆栈.如果您没有任何调整大小的逻辑,那显然会失败.但是,将 9 硬编码到测试中似乎是个坏主意,因为您会将 Stack 的内部实现细节合并到测试中.

You could write a test that pushes a ninth item onto the stack. That would clearly fail if you don't have any resizing logic. However, hard-coding the 9 into the test seems like a bad idea, since you would be incorporating internal implementation details of the Stack into the tests.

现在,编写 TDD 测试通常会告知作者其 API 中可能存在的差距.在这种情况下,测试希望能够指定堆栈的初始预分配大小.然后它可以将它设置为 8 或 2 或其他什么,然后再推送一个项目.并且,认为其他客户也可能想要它并非不切实际(例如,它类似于 std::vector 的保留方法).所以,我会考虑向 Stack 添加一个构造函数参数来指定初始保留大小,默认为 8,并添加一个 Should_Not_Error_When_Pushing_More_Items_Than_Initial_Size 测试.

Now, the writing of TDD tests often informs the author of possible gaps in his API. In this case, the test would like to be able to specify the initial pre-allocation size of the Stack. Then it could set it to 8 or 2 or whatever and push one more item than that. And, it is not unrealistic to think that other clients might want that too (it is similar to the reserve method of std::vector, for example). So, I would think about adding a constructor parameter to Stack to specify initial reserved size, default it to 8, and add a Should_Not_Error_When_Pushing_More_Items_Than_Initial_Size test.

这篇关于如何协调 TDD 与 SUT 接口的合同?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆