在文章测试所需行为而不是附带行为中,Kevlin Henney告诉我们:
"[...]测试中常见的陷阱是对测试的具体细节进行硬连线测试,其中这些细节是偶然的,与所需的功能无关."
但是,在使用TDD时,我经常会为偶然行为编写测试.我该怎么办这些测试？抛弃它们似乎是错误的,但文章中的建议是这些测试可以降低敏捷性.
将它们分成单独的测试套件怎么样？这听起来像是一个开始,但直觉上似乎不切实际.有没有人这样做？
根据我的经验，依赖于实现的测试很脆弱，并且会在第一次重构时大量失败。我尝试做的是在编写测试时专注于为类派生适当的接口，从而有效地避免接口中的此类实现细节。这不仅解决了脆弱的测试，而且还促进了更简洁的设计。
这仍然允许进行额外的测试来检查我选择的实现的危险部分，但只是作为对我的类的“正常”接口的良好覆盖的额外保护。
对我来说，当我在考虑实现之前就开始编写测试时，重大的范式转变就发生了。我最初的惊讶是生成“极端”测试用例变得更加容易。然后我认识到改进的界面反过来又帮助塑造了其背后的实现。结果是，我现在的代码除了接口公开之外并没有做更多的事情，有效地减少了大多数“实现”测试的需要。
在类内部重构期间，所有测试都将有效。只有在暴露的接口发生变化的情况下，测试集才可能需要扩展或修改。