测试驱动开发是谁？

在过去的4.5年中，我一直在企业领域中工作，并且注意到，一般而言，企业对于测试优先的开发风格不是一个有利的环境。项目通常是固定成本，固定时间表和瀑布式的。任何单元测试（如果有的话）通常都在QA阶段开发后由另一个团队完成。

在为企业工作之前，我曾为许多中小型公司提供咨询服务，但没有一家公司愿意为测试优先的开发项目付费。他们通常希望开发立即开始，或者经过短暂的设计工作：即，类似于敏捷的东西，尽管有些客户希望将所有东西都映射为类似于瀑布的东西。

在哪种类型的商店，公司和客户中，测试驱动的开发最有效？哪些类型的项目倾向于有利于TDD？

我编写的每一行代码都使用测试驱动的开发。如果管理层不首先编写测试，那么我不会告诉管理层。我坚信测试驱动的开发是一个更好的过程。

今天我的老板给我喂了一个好人，我想我要偷它，就像他从别人那里偷它一样。

“您期望木匠在切割木板之前先对其进行测量吗？”

我在高中时上了木铺课，并通过学校从事建筑工作。我们的口头禅始终是“两次测量，一次切割”，然后讽刺地说道：“我将其切割并再次切割，但仍然太短了！”

如果在此之后进行测试，则会创建返工，因为将很难测试要编写的代码。当您第一次进行测试时，甚至在您提交之前进行一点中间的测试，就可以更轻松地测试自己创建的软件。编写生产代码以满足检查清单之后创建单元测试的企业正在浪费精力。

与现有的难以测试的软件集成也会带来更多的工作，因为您将需要创建测试接缝，以便能够控制闪亮的新测试驱动代码所消耗的依赖项。在某些情况下，例如使用大量使用全局状态和上帝对象的框架，这可能很难实现。测试驱动开发的感知困难通常归结为缺乏经验，编写好的测试以及尝试测试紧密耦合的代码。

您甚至可以在瀑布式项目中测试驱动代码，这是工程学科而不是项目管理技术。

无论如何，我都不是TDD的狂热者，但是它可以教给您很多有关软件设计的知识。

忍受我，因为这将具有独特的.Net风格：p

关于适合于测试优先方法的项目类型，我需要注意以下几点：

• 您正在处理现有的代码库吗？改造一个测试套件通常是非常昂贵的。了解一下继承的技术债务有多少
• 某些平台和框架本质上是无法测试的。我最近想到的最新经验-例如，对于TDD来说，SharePoint很难（但并非不可能）。对于这样的事情，您可能不得不求助于TypeMock可以帮助您的商业隔离器产品。
• 某些实施方法比其他方法更适合TDD。例如，带有代码隐藏的ASP.Net-不太容易测试。ASP.Net MVC-可测试。带有代码隐藏功能的Silverlight-不太容易测试。带有MVVM的Silverlight-可测试。

最终，尽管“组织”可以做很多事情来支持向测试优先的转变，但需要发生的关键转变是在开发人员的头脑中。我已经放弃了“您应该首先编写您的测验”的方法，而是寻找可教的时刻。

+1关于mpenrow关于不告诉mgmt是否存在问题的评论：p

您的情况不会很快改变，要想通过它，关键在于使其成为您的个人纪律的一部分，并善于应对，然后再尝试将其推向他人。如果您可以说它是行之有效的典范，那么您的经理应该看到客观的好处。

您还可以提出良好的业务案例：

• TDD可以简单地概括为“规范，系统可以自动对其进行验证”。它没有不同的编程，也没有构建不同的产品。

• 单元测试实际上只是自动化测试的一种形式。这只是让计算机自行完成该公司可能要支付的肉类空间工程师手动执行的任务。自动化测试的运行速度更快，更一致，并且编写得当可以提供快速，简洁，准确的反馈以及问题的描述和方向

• 当TDD由知道自己在做什么的人完成时，其生成结果的速度与代码优先一样快。会有一条学习/训练曲线（并且，如果您的工程师来自人才库的短端，那么这可能会完全抵消您推动TDD的机会-在这种情况下，您能做的最好的就是继续拥护它。让管理层质疑他们而不是TDD）

• TDD非常想在开始之前仔细考虑手头的任务。它遵循“两次测量，减少一次”的思路-额外的测量为任务增加了一点时间，但避免了浪费您最宝贵的资源-开发时间。

...并记住 您可以做的最重要的事情就是以身作则。如果您对TDD不满意，请花一些额外的时间来变得更好。一旦您精通，就可以在工作中开始做（您的经理真的会抱怨您编写测试吗？）。一次打一场战斗并迈出一步-整个战斗可能会导致失败，如果您为之努力奋斗，责任将落在您身上。

我做。这是我的首选发展方式，并且我在一家大型金融公司工作，只要我能按时完成并生成质量代码，我就会以我认为合适的方式工作。做得正确，测试优先开发不需要比开发后测试花费更长的时间，并且我们不要忘了测试优先开发带来的其他好处，即减少了以后的系统测试中的缺陷。

进行TDD的关键是将其作为编写代码的一部分，并且在必要时不要告诉任何人正在做的事情。 不必解释您在做什么。您的最终结果是工作代码。

如果您解释“我正在编写测试”，那么“可以的力量”可以说“哦，我们可以消除它！” 但是，如果您不告诉任何人，那么测试仍然是编码过程的残余。

编程不仅仅是在编辑器中输入工作语句。如果人们无法解决这个问题，那么请让他们远离这个真理，直到他们准备好应对它为止。在这种情况下，“准备好处理”意味着当您有一个或两个完整的项目时，使用可靠的可靠代码按时完成，哦，是的，您也要进行单元测试。

可悲的是，我还没有得到机会使用它在真正的经典试验，第一次感觉自己，所以我不能说“我！我！我能行！”。我假设问题是在问“哪些行业/公司全面使用TDD”，而不是“任何人都可以将TDD纳入日常生活？”。我同意，单个开发人员可以完全执行TDD，而不必强迫整个团队都这样做，我只是不认为这是问题的重点。

从行业内的倾听给我的印象是，在以下情况下，您更有可能在公司的大多数开发团队中看到TDD：

• 在TDD出现之前，没有大量的现有代码库

• 该公司规模不大，因此没有很多“我们一直以其他方式做到”的推后推销。

• 该公司对正式流程没有很大的投入。这并不是说您无法在CMMI认证的公司中实施TDD，但是，如果您拥有非TDD流程，那么更新您使用CMMI监控的所有流程可能是一项重大投资。

• 可以编写测试脚本-这是最复杂的代码库，因为即使您不能轻松编写与用户最接近的图层，也可以编写一些内部脚本。但是我认为，针对测试自动化开发完善的选项的情况是TDD的最甜蜜之处，因为它基于重新运行并且不会破坏整个测试过程，在这些测试中您需要非常快速的测试反馈。我的想法是，一个独立的Web应用程序是一个很好的TDD目标，一个具有主要COTS集成或不基于GUI的输入的系统可能很棘手。

• 系统处于非原型状态。理想的情况是原型之后的下一个大型版本-概念验证已完成，项目已获得资金，但每个人都知道下一次尝试必须提高质量。

• 在此过程中投入的利益相关者。

我已经尽力了-但我认为这实际上取决于您所处的公司环境。我在游戏行业工作了多年（作为一名艺术家），没有TDD的概念-只是蛮力的QA方法。我从事Web开发，还没有在具有任何正式认可（或了解...）单元测试/ TDD的代理机构中工作。对于本行业中大多数从事广泛学科工作的同行来说，情况也是如此。

在以销售为中心的代理机构中，TDD很少为客户提供短期 ROI，因此在确定项目范围时很难将其出售给直属经理。但是，项目规模越大，说服力就越大。

鉴于诸如《死亡进行曲》之类的书指出了一种普遍现象，即一个行业受到“紧缩”和“里程碑”驱动的发展困扰-我敢打赌，TDD在资金雄厚的初创公司或大型企业商店中可能很少见。不是说那里的人不相信TDD的价值-但这太抽象了，无法卖给他们的客户。

我正在尝试自己参与TDD。我认为，只要您遵循已经知道的路线（日常工作），就很简单。但是，我只是无法将注意力集中在UI部分的测试上，或者当您不得不为以前从未遇到过的某些问题提出新的解决方案时。或使用您不知道的框架。

因此，我想您必须进行某种LearningTests测试，单独的概念验证并在以后进行重写等，否则我错了吗？

并且（我知道这是一个古老的方法，但是我还没有看到一个好的答案）：如何使用TDD编码算法（当结果可能很复杂，很难真正地“断言”时）？

我确实可以看到TDD和即时消息的积极方面，但是对于初学者来说，当您编写的代码花费几乎两倍的时间时，这是非常困难的（并且您的同行完全看不到专业人士并嘲笑您）使用RAD）

我尝试了几次，效果很好。不幸的是，大多数情况下，如果我可以手动测试我的应用程序，我会推迟单元测试，直到我觉得无聊无法实现其他功能或存在无法轻易修复的错误为止。

我做 我们的用户故事的进度是在看板上跟踪的，看板上有一个“已测试？”。开发左侧（上游）的列。

这种有些不寻常的布局使一个策略明确了：必须存在一个失败的自动接受测试（通常是其中的几个）。它必须可追溯到客户需求。接受测试来自满足条件，满足条件是从故事卡开始的对话中得出的。我为定期举办的研讨会提供了便利，我们在这里集体讨论需求，发现差距并找出关键的验收测试，以确保用户通过时能够传递其价值（完成的定义）。这是一个协作活动，涉及程序员，业务分析人员，有时还包括测试人员。

验收测试反馈循环相当长：完成故事可能需要几天。该开发具有自己的较短的TDD反馈回路。

“ [...没有测试优先的样式...]更类似于敏捷。

这是对敏捷的完全错误陈述。 完成的定义是敏捷的关键组成部分，它所依赖的支柱之一是自动验收测试（我上面所描述的是实现这一目标的一种方法。）如果将极限编程（XP）用作敏捷的实现方法，则规定了ATDD / BDD和TDD。

我可以，但是通常只适用于非ui组件，当我知道无法一次将模块的整个算法保存在脑海中时，或者当该模块是我正在使用的任何系统的新组成部分时，因此，我不能依靠自己使用的大多数库进行高度调试。

本质上，当需求的复杂性意味着我可能会迷失在代码中时，我就会这样做。

这是一个很难养成的习惯，并且确实需要管理层的支持，但是，当您的测试在开发中途中断时，它可以挽救生命！

我想问这个问题，以了解实际上有多少公司在实践TDD。

在我从事专业编程的11年中，只有后两个组织才意识到TDD（这涉及了将近5年的时间，在此之前TDD并不像今天那样流行）。在深入探讨TDD的销售建议之前，我会尽力地回答您的问题：)

在我工作的最后一家公司（人文和科学收藏在线学术出版商）中，我们知道我们需要练习TDD，但我们从未真正做到这一点。在我们的辩护中，我们有25万个代码库，因此将测试添加到这种大小的不可测试代码库中是无法克服的（我现在感到内feel！）。即使是我们最好的人也会犯错。

甚至只做了少量TDD的人都知道，对未经测试的棕场代码进行艰苦的改造测试可能是多么痛苦……主要原因是隐式依赖（您无法拉动所有手段来断言代码的结果-您无法嘲笑）场景）和违反单一职责原则（测试复杂，人为设计，需要太多设置且难以理解）。

我们暂时将质量检查小组（从一个人，可能是两个人增加到六个人或更多）组成，以测试该平台，然后再发布任何版本。在时间和金钱上，这是非常昂贵的时间，某些版本需要三个月才能完成“测试”。即使那样，我们仍然知道我们遇到了问题，它们不是“阻碍”或“严重”问题，而不仅仅是“高优先级”问题。

如果您有多年的商业经验，您会感激每家公司都会执行关键任务，然后发明一个更高的优先级，也可能是更高的优先级-尤其是当上面的某个人在推动功能/错误修复时。我离题了...

我很高兴地报告，我正在我当前的公司（电信，Web和移动应用程序开发公司）内实践TDD，并与Jenkins CI一起提供其他静态分析报告（在断言测试套件通过之后，代码覆盖率是最有用的） 。我使用TDD的项目是支付系统和网格计算系统。

销售点...

证明对非技术团队成员进行自动化测试通常是艰巨的努力。编写测试确实会增加开发过程的工作量，但是...现在投资测试时间，以后可以节省维护工作。你真的只是在借时间。产品使用的时间越长，您可以节省的费用就越大-并且可以帮助您避免进行大量的重写。

首先进行测试意味着您首先要编码您的意图，然后确认您的代码满足该意图。这提供了焦点，并且提炼了您的代码，使其仅执行预期的操作，而不再执行任何操作（请勿膨胀）。它同时是一个可执行的规范和文档（如果您的测试写得很好，并且测试应该与您的系统代码一样可读/干净，甚至更多！）。

非程序员（通常）没有这种见识，因此TDD对他们而言没有太大的价值，并且被视为可以提前发布早期版本的捷径。

编程是我们的专长，在我看来，这是我们作为专业人员对像TDD这样的最佳实践提供建议的责任。不是由项目经理决定是否要减少开发时间，而是超出他们的管辖范围。以相同的方式，他们不会告诉您使用什么框架，缓存解决方案或搜索算法，也不会告诉您是否应该使用自动化测试。

在我看来，软件开发行业（总体上）目前处于崩溃状态，对您的软件进行测试不是正常的事实。

在其他行业中想象一下：医疗，航空，汽车，化妆品，毛绒玩具，酒精饮料等。我要求未婚妻列出一个行业，他们不测试产品，而她不能测试产品！

说没有测试是不公平的，因为它确实会发生……但是在没有自动化测试的公司中，这是非常手工/人工（读取笨拙且经常容易出错）的过程。

我要在您的问题中争论一点...

他们通常希望开发立即开始，或经过短暂的设计工作。更类似于敏捷。

“敏捷”并没有规定未经测试就可以继续进行，agilemanifesto.org上列出的第一位成员是XP和TDD的创建者Kent Beck！

如果您对TDD感兴趣，或者只是不读而又热衷于编程，我会极力推荐两本书。

通过测试引导不断发展的面向对象的软件

清洁代码-罗伯特·C·马丁（鲍勃叔叔）系列

这两本书互相称赞，并且将很多意义浓缩为几页。

感谢您提出这个问题:)

那些实现克隆的人。当您开发与现有程序完全一样的东西时，我想不出更好的过程。

显然，这是一个非常不寻常的情况，但是SQLite的开发人员广泛使用测试。（尽管不确定，我认为他们的开发过程是测试先行的。）

• 73,000行代码
• 91,378,600行测试代码

参见http://www.sqlite.org/testing.html