unit-testing - 测试所需行为与 TDD

Question

文章中Test for Required Behavior, not Incidental Behavior ，Kevlin Henney 建议我们:

"[...] a common pitfall in testing is to hardwire tests to the specifics of an implementation, where those specifics are incidental and have no bearing on the desired functionality."

但是，在使用 TDD 时，我经常会为偶然行为编写测试。我该如何处理这些测试？扔掉它们似乎是错误的，但文章中的建议是这些测试会降低敏捷性。

将它们分成一个单独的测试套件怎么样？这听起来像是一个开始，但直观上似乎不切实际。有人这样做吗？

Answer 1

根据我的经验，依赖于实现的测试很脆弱，并且会在第一次重构时大量失败。我尝试做的是在编写测​​试时专注于为类派生适当的接口(interface)，从而有效地避免接口(interface)中的此类实现细节。这不仅解决了脆弱的测试，而且还促进了更简洁的设计。

这仍然允许进行额外的测试来检查我选择的实现的危险部分，但只是作为对我的类的“正常”接口(interface)的良好覆盖的额外保护。

对我来说，当我在考虑实现之前就开始编写测试时，重大的范式转变就发生了。我最初的惊讶是生成“极端”测试用例变得更加容易。然后我认识到改进的界面反过来又帮助塑造了其背后的实现。结果是，我现在的代码除了接口(interface)公开之外并没有做更多的事情，有效地减少了大多数“实现”测试的需要。

在类内部重构期间，所有测试都将有效。只有当暴露的接口(interface)发生变化的情况下，测试集才可能需要扩展或修改。