我们将XP中的单元测试称为“微测试”，因为之前总是要跟别人解释XP的的单元测试跟传统意义上的单元测试的不同，既繁琐又容易出错。这样命名以后，至少可以部分避免发生上述问题的几率。
讨论是由Ben Hall的问题引起的，他发现（不从事编程的）测试人员群体不像其他社区那么活跃，对此他觉得很疑惑：
社区里的测试人员都哪里去了？开发人员很容易找，从大型会议（PDC、TechED）到小型用户组（NxtGenUG），类似的活动很多。两年前，NxtGenUG在考文垂举办首次活动，从那时起我就是它的成员了；而且我还参加TechED Europe会议。但是在这些活动中为什么见不到测试人员？还是我眼拙没注意到？
我知道公司的招聘人员们一直对此问题感到疑惑，但是从社区的角度来看——测试人员都去哪儿了？他们的交流在哪里进行？如何改进软件测试、测试人员如何融入到项目结构中、测试人员如何利用最新的开发技术？类似的问题一定会有人关心的，但是这些人在哪里？
很有意思，对Ben的问题的最初回应是这么说的：“是有这样的社区的，但是他们比较孤立，很大一部分原因是为了避免由于用词混淆带来的沟通误解”。由此激起了大家更热烈的反响，讨论使用新词汇所能带来的好处，比如用“微测试”表示TDD中程序员使用的“单元测试”方式。
Hill带头，强调了他使用“微测试”所带来的正向产出，新的XP团队因此理解了单元测试的着眼点是放在极其细微的测试“单元”之上，而不是传统的非XP开发过程中所着眼的、较大范围的“单元”。Mike不只强调了这个区别，他还指出了TDD和微测试的真实意图及其与传统测试意图的差异。
我们发现：密集的微测试驱动开发带来的好处不仅仅是提高质量。质量的提升是TDD的一个副作用。实际上，我们所传授的TDD的好处和真正意图，是要指导生产力：更多功能，更快发布。
很多帖子都对Mike的主意表示赞同。其中，XP大牛Ron Jeffries说道：
我非常同意这才是TDD真正的好处，我也很仰慕你［如此自信］敢于直接把它讲出来。
此外，这个讨论的有趣和有用之处在于引发的众多不同观点和实例，展示了引入“微测试”这样的词汇所带来的优劣之处，比如一个内容充实的列表，列出了真正的微测试的特征。
文章来源于领测软件测试网 https://www.ltesting.net/
