将单元测试用作“功能契约”

听起来是个好主意。我(我们大家?)经常在内部使用单元测试来实现这一点。在使用我的单元测试来验证我没有破坏任何东西的过程中,我还隐式地验证了我的API契约没有改变。单元测试的自然用法似乎是按照您所说的方式部署它们。

敏捷方法说: ,所以这是一个非常好的主意。

我完全希望为此受到批评,但我不明白一组单元测试如何证明客户关心的事情,即应用程序是否满足其业务需求。

这里有一个例子:我刚刚完成了一段代码的转换,以修复我们犯下的一个大错误。这是一个典型的过度工程的例子,这些变化已经影响了十几个windows窗体和大约同样多的类。

这花了我几天的时间,现在简单多了,我们免费获得了一些特性,我们丢失了大量代码,这些代码做了我们现在知道从未真正需要的东西。

这些表格中的每一张以前都工作得很好。公共方法做了它们需要做的事情,底层数据访问也很好。

所以任何单元测试都会通过。

遗憾的是,他们做了错事——我们没有意识到,只是回顾过去。这就好像我们已经建立了一个原型,只有在尝试使用它之后,才意识到它是不对的。

现在我们有了一个更精简、更吝啬、更适合的应用程序。

但是错误的地方,在单元测试无法揭示的程度上是错误的,所以我只是不理解在安装时发布一组单元测试除了给人一种错误的安全感之外,还能做什么。

也许我不了解一些东西,但在我看来,除非装运的东西 功能 在与提供的测试相同的水平上,它们证明不了什么。

这实际上是一个非常好的主意,作为一个API用户,它非常令人愉快。

这种技术实际上也可以反过来使用:当您使用“遗留”API时,您可以使用单元测试来记录您认为该API的行为方式,并验证它是否确实按照计划运行。

如果您正在发布 ,听起来不错。

如果您发布的是一个普通的软件产品,您的用户只能通过 桂

如果您对在代码中提供一组规范感兴趣,也许您应该研究一些行为驱动的开发工具(nbehad、jbehave、rspec等)。这些框架支持用给定的/when/then语法描述测试,并输出自然语言的格式化结果。看见 nbehave 以.NET的BDD工具为例。您可以找到关于BDD的极好描述 here

另一种选择是使用验收测试框架编写测试,如 fit 或 fitnesse concordion )并按照规范交付这些验收测试。fit/fitnesse和concordion都允许在普通HTML甚至Word文档中指定测试。

这两种方法(BDD或验收测试框架)的好处是,用户看到的结果更易于理解。

需求定义功能

问题是,只能检查单元测试可以覆盖的功能。集成或整个系统测试将不起作用。

Meszaros 称之为“测试为文档”