对于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真正的好处,我也很仰慕你[如此自信]敢于直接把它讲出来。

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