我的“单元测试”跟你的是两码事！

作者 Mike Bria译者 郑柯 发布于 2008年6月26日 上午4时48分

社区

Java,

Agile,

.NET,

Ruby

主题

软件测试,

单元测试

标签

测试,

生产力,

测试驱动开发

对于TDD的“单元测试”与传统的“单元测试”之间的差异，业界一直存在着误解。知名的XP贡献者Mike Hill，对这些误解进行了澄清。他还特别讲述了在Industrial Logic的经历，在那里展开教学时，他和其他人一起使用“微测试（microtests）”这个词汇来指代TDD的单元测试，避免产生“单元测试”概念上的混乱。

我们将XP中的单元测试称为“微测试”，因为之前总是要跟别人解释XP的的单元测试跟传统意义上的单元测试的不同，既繁琐又容易出错。这样命名以后，至少可以部分避免发生上述问题的几率。

讨论是由Ben Hall的问题引起的，他发现（不从事编程的）测试人员群体不像其他社区那么活跃，对此他觉得很疑惑：

社区里的测试人员都哪里去了？开发人员很容易找，从大型会议（PDC、TechED）到小型用户组（NxtGenUG），类似的活动很多。两年前，NxtGenUG在考文垂举办首次活动，从那时起我就是它的成员了；而且我还参加TechED Europe会议。但是在这些活动中为什么见不到测试人员？还是我眼拙没注意到？

我知道公司的招聘人员们一直对此问题感到疑惑，但是从社区的角度来看——测试人员都去哪儿了？他们的交流在哪里进行？如何改进软件测试、测试人员如何融入到项目结构中、测试人员如何利用最新的开发技术？类似的问题一定会有人关心的，但是这些人在哪里？

很有意思，对Ben的问题的最初回应是这么说的：“是有这样的社区的，但是他们比较孤立，很大一部分原因是为了避免由于用词混淆带来的沟通误解”。由此激起了大家更热烈的反响，讨论使用新词汇所能带来的好处，比如用“微测试”表示TDD中程序员使用的“单元测试”方式。

Hill带头，强调了他使用“微测试”所带来的正向产出，新的XP团队因此理解了单元测试的着眼点是放在极其细微的测试“单元”之上，而不是传统的非XP开发过程中所着眼的、较大范围的“单元”。Mike不只强调了这个区别，他还指出了TDD和微测试的真实意图及其与传统测试意图的差异。

我们发现：密集的微测试驱动开发带来的好处不仅仅是提高质量。质量的提升是TDD的一个副作用。实际上，我们所传授的TDD的好处和真正意图，是要指导生产力：更多功能，更快发布。

很多帖子都对Mike的主意表示赞同。其中，XP大牛Ron Jeffries说道：

我非常同意这才是TDD真正的好处，我也很仰慕你［如此自信］敢于直接把它讲出来。

此外，这个讨论的有趣和有用之处在于引发的众多不同观点和实例，展示了引入“微测试”这样的词汇所带来的优劣之处，比如一个内容充实的列表，列出了真正的微测试的特征。

要想查看完整内容，您可以点击该链接，并可以让读者知道您对这个问题怎么看。

要想了解更多关于“微测试”的内容，请查看Industrial Logic的“超级精选”学习专辑，以获得关于该主题的、基于web的培训内容和其他许多主题。

查看英文原文：My "Unit Test" Aint Your "Unit Test"

---

在infoq英文站上，有读者对该新闻的评论如下：

我从来都没有意识到存在这样的困惑。文中所述的“微测试”正是我所理解的单元测试。也许有人能告诉我别人是怎么理解单元测试的？

看来，传统意义上的单元测试已经有从国外软件开发人员的视野中淡出的迹象。

• 更早的 >