在企业向敏捷转型的各种实践中，TDD通常是最艰难的一个。
这对美国犹他州Midvale的IBM软件组来说是确确实实的体验。他们从2007年就开始向敏捷转型。IBM开发转型部门副总裁Sue Mckinney认为，测试驱动开发前景非常诱人，但是“在这个过程中我们的付出可能也是最多的。”
Mckinney说：“虽然我们做了大量的自动单元测试和功能测试，集成测试也做得越来越好，但是这毕竟是一种意识问题。开发人员喜欢编写代码，他们一点儿也不喜欢做测试。”
她又补充道，但这是他们必须经历的一段旅程，“我们通过兼并获得一些优秀的设计师，他们在TDD方面有很不错的经验，值得我们效仿。我们请他们将经验和大家分享。这将是我们2009年的重点工作——让我们的团队学习TDD。”
TDD根源于极限编程（XP），通常指开发人员在编写代码之前创建用于对代码进行自动单元测试的实践。Kirk Knoernschild是Burton集团的一位分析师。他列举了这个过程中所面临的挑战：“如果单元太大就很难写出高质量的测试。并且，虽然许多组织都说他们的开发人员在写单元测试，但是实际上他们也不知道自己的代码覆盖率有多高。还有许多组织仍然会把测试阶段推迟到软件周期的后期，这无疑会使问题变得更严重。”
旧代码也会产生问题。据AMS Services的首席架构师Chris Kinsman说，虽然AMS已经提高了对代码的单元测试和集成测试的力度，但是他们并没有做太多TDD方面的工作。“我们现在有大量的非TDD代码。旧代码几乎没有测试驱动的。”Chris表示，“部分团队做过TDD方面的短期努力，但那不等于在全部团队都采用了这个实践。”
他认为，AMS不一定会把TDD作为目标，“我担心我们的代码基础可能不支持这么做。在走这一步之前，我们还要先解决一些架构上的问题。我并不是从理论上反对这么做，我只是不想把我们当前的工作弄得更辛苦而已。”
Knoernschild认为，测试驱动开发所面临的另一难题是它给人一种会减缓开发团队速度的感觉。复式记账法就是一个很好的类比。如果会计不使用复式记账法，那么他的工作会快很多。但是这样的结果就是一旦出错他无法（轻松地）使用制约系统进行检查。测试也是如此。一旦出现了问题，你会发现你缺少相应的制约系统来检查并确定问题的根源所在。
虽然TDD确实会减缓工作速度，但是长远看来，“随着代码的增长，它实际上是会提高速度的。”
Forrester的分析师West认为，这是一种文化上的转变，“以前的软件工程师在拿不定主意的时候会写许多文件，但是这些文件都没有说到痛处。因为这时候没有让你战胜这个问题的环境，缺少的是一种氛围。”
West还说道，开发人员在写测试之前可能需要先研究一些东西，“并不是说你不喜欢这种方式，而是在你写出一部分编码、了解到一个大概之前，你无法真正地明白问题，也就无法写出测试来。而在敏捷所提倡的探索性过程中，你可以更好地了解问题所在，相应地也就会更习惯于这种做法。”
West认为，测试资源按部门划分的方法也是一个障碍，“某些供应商要为此负责，因为他们鼓励卓越中心的做法——即专门负责QA的部门。这使得很难从早期就开始QA方面的工作，所以你只能在没有QA的情况做敏捷工作。你确实会做单元测试，但是你把它和其它工作分开了，因为它们属于不同的部门。”
网络内容管理公司Vignette已经开始接受TDD，但也只是刚开始。其工程部主任Subu Subramanian说，“如果团队考虑了需求描述和验收标准，他们会把这些详细地写到测试里，这样他们在进行设计和开发的时候就会同时考虑测试。”他表示，Vignette的最终目标是把测试带入到开发周期的早期阶段。
虽然这不是敏捷的一部分，却可以为测试驱动开发带来意想不到的效果。他说，“虽然TDD通常会和敏捷开发联系在一起，也是敏捷实践的一种，但是即使你没有把全部精力都投入到敏捷当中，TDD的价值也是显而易见的。从你写下第一行代码的时候，你就可以把测试带入开发周期。你可以在编写代码的同时生成相应的测试集。”
他还补充说，“如何执行TDD取决于你的企业结构。你必须根据实际情况做决定。比如可以是一种两人工作的模式，一人写测试，一人写代码。”
不管TDD将来如何发展，各企业都需要“尽可能地在早期阶段把尽量多的精力放到质量与测试当中”。
文章来源于领测软件测试网 https://www.ltesting.net/