虽然这听起来很诱人，但是这不现实，因为：TDD中开发的白盒的单元测试的粒度和目标与黑盒测试有所区别。
单元测试的总体目标是用于证明代码是如预期般工作的，而回归测试的目的是确保修改的代码不会引起非预期的结果。两者存在的意义是不一样的，例如，"检查某个属性的日期格式是正确的"，就与"对于给定的输入，检查其值具有预期的日期"不一样。
神话3："我们不再需要测试人员、或者自动化工具"
专业的测试人员履行了不一样的职责，与开发同僚们一样是不可或缺的项目组角色之一。
不得不承认：传统的自动化测试工具并没有像厂商们所鼓吹的那样神奇。但是这不意味着我们要放弃自动化工具，我们仍然期待更多更好的自动化工具的出现。
#FormatImgID_1#
神话4："有了单元测试，手工测试就没有存在的必要性了"
手工测试时重复性的劳动，代价高、繁琐、容易出错。然而，虽然TDD能减少一定量的手工功能测试，它并不能废除进一步的黑盒测试的需要（无论是手工的还是自动化的）。
通过自动化的捕获测试人员的操作过程，并且将他们的键盘和鼠标点击事件文档化，测试人员可以把更多的时间放在有趣的、增值的活动上，例如测试那些自动化很难实现，或者是根本不可能实现的复杂测试场景。虽然通过手工测试寻找bug是一个耗时的、代价高昂的过程，但是如果不采用这种手段而遗漏了BUG，代价会更高。
神话5："不再需要用户验收测试"
在敏捷开发中，用户验收测试通常用于与顾客一起解决"不正确的需求"的问题，而不是用于纠正功能问题。
当用户最初定义需求时，他们是基于自己的初始想法和愿景来定义的。当他们看到"活生生的"真正的系统后，他们总是会有不同的、额外的需求。虽然敏捷方法可以减少这种情况发生的频率，但是也不可能杜绝，因此也就不可避免地需要用户验收测试。
神话6："自动化是不可能的"
在敏捷项目的早期阶段开展自动化测试通常是很困难的，但是随着系统的演进，某些方面稳定下来之后就可以开始实施自动化测试了。
洞悉自动化测试开展的正确时机并不容易，因此，使用某些技术，让早期的手工测试可以顺利过渡到自动化测试是很关键的。如果早期的测试设计和手工测试可以被很好地记录下来，以备重用的话，后面的自动化测试将大大受益。
神话7："开发人员拥有足够的测试技巧"
如果测试是很容易的，那么每个人都可以做，则每次我们都可以发布和交付优质的代码。一个独立的测试组的目标是作为第三方、能够从全局出发、验证和确认软件功能的质量。而开发人员趋向于证明系统是正常工作的。一个好的测试者会倾向于"假设"某些场景的出现，再加上业务用户的测试，则确保系统满足预期目的将变得容易。
文章来源于领测软件测试网 https://www.ltesting.net/
