我是一名有很多经验的合同程序员。我习惯于被客户雇用进入我自己的某种形式的软件项目，通常是从零开始。这意味着几乎每次都是干净的石板。我可以引入我开发的库来快速启动，但它们总是可选的。 （并且取决于在合同中获得正确的IP条款）很多时候我可以指定甚至设计硬件平台......所以我们在这里谈论严肃的自由。
我可以看到用于构建某些代码的自动化测试的用途：具有更多简单功能的库，具有大量引用的核心功能等。基本上，随着一段代码的价值在大量使用中上升，我可以看到它自动测试该代码将变得越来越有价值，以便我知道我不会破坏它。
然而，在我的情况下，我发现很难合理化任何东西。我会采用它们证明有用的东西，但我不会盲目跟随任何事情。
我发现我在“维护”中所做的很多事情实际上都是小的设计变化。在这种情况下，测试不会为我节省任何东西，现在他们也必须改变。高度迭代，存根优先的设计方法对我来说非常有效。通过更广泛的测试，我无法看到实际上节省了很多时间。
业余爱好项目更难以证明......他们通常都是从周末到月份的任何事情。边缘案例错误很少发生，它只是玩弄东西。
阅读问题，如this one，最响应的回应似乎说，在海报的经验/意见TDD实际上浪费时间，如果你少于5人（即使假设具有一定水平的TDD能力/经验）。但是，这似乎涵盖了初始开发时间，而不是维护。目前尚不清楚TDD如何在项目的整个生命周期中叠加。
我认为TDD可以成为提高整个行业产品质量的有价值目标的一个很好的步骤。尽管如此，理想主义本身不再能够激励我。
我认为TDD对于大型团队或任何包含至少一个不可靠的程序员的团队来说都是一个很好的方法。那不是我的问题。
为什么一个拥有良好记录的唯一开发人员会采用TDD？
我很想知道在TDD上完成的任何指标（正式与否）......专注于独立开发人员或非常小的团队。
如果做不到这一点，你个人经历的轶事也会很好。 :)
如果没有经验，请避免说出意见。让我们不要把它作为一场意识形态战争。此外，跳过更大的就业选择论点。这只是一个效率问题。
我不会盲目跟随任何事情。
这是正确的态度。我一直使用TDD，但我并不像某些人那样严格遵守。
支持TDD的最佳论点（在我看来）是当你最终进入项目的重构和维护阶段时，你可以运行一组测试。如果这是您使用TDD的唯一原因，那么您可以随时编写测试，而不是盲目地遵循该方法。
我使用TDD的另一个原因是编写测试让我开始考虑我的API。在写这篇文章之前，我不得不考虑如何使用类。让我进入这个高水平的项目对我来说很有用。还有其他方法可以做到这一点，如果你发现其他方法（有很多）可以做同样的事情，那么我会说继续做对你有用的方法。
我倾向于同意你的观点对于“一个开发者”或“爱好”项目的TDD开销的有效性。
但是，如果长期一致地应用它们，则必须考虑大多数最佳实践是相关且有用的。
例如，TDD在长时间内保存测试/错误修正时间，而不是在您创建第一个单元测试后的5分钟内。
您是合同程序员，这意味着您将在完成后离开当前项目并切换到其他项目，最有可能是在另一家公司。您当前的客户必须维护和支持您的应用程序。如果你不让支持团队成为一个好的框架，他们就会被困住。 TDD将帮助该项目实现可持续发展。它将增加代码库的稳定性，因此其他经验较少的人将无法在尝试更改它时造成太多损害。
这同样适用于业余爱好项目。你可能已经厌倦了，并希望将它传递给某人。你可能会在商业上取得成功（想想Craiglist），除了你之外还会有5个人在工作。
即使只是获得了经验，对正确过程的投资也总能得到回报。但是大多数时候你会感激的是，当你开始一个新项目时，你决定正确地做到这一点
在做某事时你必须考虑其他人。你必须提前思考，计划增长，计划可持续性。
如果你不想这样做 - 坚持牛仔编码，这样就简单得多了。
附：同样的事情适用于其他做法：
等至无穷远
没有合理的单元测试，我不再重构任何东西。
我不首先使用单元测试进行全面的TDD，然后是第二代。我做CALTAL - Code A LIttle，Test A Little - development。通常，代码优先，但并非总是如此。
当我发现我必须重构时，我确保我已经有足够的测试，然后我完全相信我不需要保留整个旧架构变成新架构的结构计划在我脑海里。我只需要让测试再次通过。
我重构了重要的一点。获取现有的测试套件。
然后我意识到我忘记了一些东西，我又回到了CALTAL开发的新东西。
然后我看到了我忘记删除的东西 - 但它们到处都没用吗？删除它们，看看测试中的失败。
就在昨天 - 通过大规模重构的一部分 - 我意识到我仍然没有完全正确的设计。但测试仍然需要通过，所以在我完成第一次重构之前，我可以自由地重构我的重构。 （哇！）这一切都很顺利，因为我有一套测试来验证变化。
飞行独奏TDD是我的副驾驶。
TDD让我更清楚地定义了脑海中的问题。这有助于我专注于实现所需的功能，仅此而已。它还有助于我创建更好的API，因为在编写代码之前我正在编写“客户端”。我也可以重构而不必担心破坏任何东西。
我会很快回答这个问题，希望你会开始看到一些推理，即使你仍然不同意。 :)
如果你足够幸运能够参与一个长期运行的项目，那么有时你会想要在向上移动堆栈之前首先编写数据层，然后编写业务层。如果您的客户端随后需要更改需要在数据层上重新处理的需求，那么对数据层进行一系列单元测试将确保您的方法不会以不合需要的方式失败（假设您更新测试以反映新的需求） ）。但是，您可能也会从业务层调用数据层方法，并且可能在多个位置调用。
假设你有3次调用业务层中的方法，但你只修改2.在第三种方法中，你可能仍然从数据层获取看似有效的数据，但可能会破坏你的一些假设编码前几个月。此级别（及以上）的单元测试应该设计为发现破坏的假设，如果失败，他们应该向您强调有一部分代码需要重新访问。
我希望这个非常简单的例子足以让你更多地思考TDD，它可能会产生一个让你考虑使用它的火花。当然，如果你仍然没有看到这一点，并且你对自己跟踪成千上万行代码的能力充满信心，那么我没有地方可以告诉你应该启动TDD。
关于编写测试的要点是它强制执行您正在制定的要求和设计决策。当我修改代码时，我想确保它们仍然是强制执行的，并且很容易在没有编译器或运行时错误的情况下“破坏”某些东西。
我有一个测试优先的方法，因为我希望对我的代码有很高的信心。当然，测试需要进行良好的测试，否则他们不会执行任何操作。
我有一些相当大的代码库，我工作，并有很多非平凡的东西正在进行。当X永远不会发生时，很容易做出波动和突然发生X的变化。我的测试几次使我免于犯了一个可能被人类测试人员忽视的关键（但微妙）错误。
当测试失败时，他们有机会查看它们和生产代码并确保它是正确的。有时设计会发生变化，需要修改测试。有时我会写一些通过100次测试中的99次的东西。那个没有通过的测试就像一个同事在审查我的代码（在某种意义上），以确保我仍在构建我应该构建的东西。
我觉得作为一个项目的独立开发者，特别是一个更大的项目，你往往会变得非常薄。 您正处于大型重构的过程中，突然发现一些关键错误，这些错误由于某些原因在预发布测试期间未显示出来。在这种情况下，你必须丢弃所有东西并修复它们，在花了两周时间撕掉你的头发之后你终于可以回到你以前做过的任何事情了。 一个星期后，你的一个最大的客户意识到他们绝对必须拥有这个很酷的新亮点功能，否则他们不会下订单他们应该在一个月前订购的那些1M单位。 现在，三个月后你甚至都不记得你为什么开始重构，更不用说你重构的代码应该做什么了。感谢上帝，你做了很好的编写单元测试，因为至少他们告诉你，你的重构代码仍在按照它应该做的去做。 泡沫，冲洗，重复。
我过去6个月的生活故事。 ： - /
唯一的开发人员应该在他的项目中使用TDD（跟踪记录无关紧要），因为最终这个项目可以传递给其他开发人员。或者可以引进更多的开发人员。
没有测试，新人将非常难以使用代码。他们会打破局面。
您的客户在交付产品时是否拥有源代码？如果您能说服他们通过单元测试交付产品可以增加价值，那么您就可以向上销售服务并提供更好的产品。从客户端的角度来看，测试覆盖率不仅可以确保质量，还可以让未来的维护者更容易理解代码，因为测试将功能与UI隔离开来。
我认为TDD作为一种方法论不仅仅是“在进行更改时进行测试”，因此它不依赖于团队或项目规模。这是关于注意到一个人对一个代码/一个应用程序的作用的期望在一个人开始真正思考如何实现所述行为之前。 TDD的主要焦点不仅是对编写代码进行了测试，而且编写了更少的代码，因为您只是做了使测试成为绿色（以及稍后重构）的代码。
如果你像我一样，很难想到部分/整个应用程序的作用而不考虑如何实现它，我认为在代码之后编写测试并因此让代码“驱动”试验。
如果您的问题不是关于测试优先（TDD）或测试优先（良好的编码？）我认为测试应该是任何开发人员的标准做法，无论是单独的还是大团队，他们创建的代码都保留在生产中超过三个月。在我的经验中，即使原始作者必须仔细思考这些二十行复杂的，超级优化的，但是稀疏文档的代码真正代码所做的事情。如果你已经完成了测试（涵盖了代码中的所有路径），那么就会更少思考 - 甚至更少的ERR，甚至几年之后......
以下是一些模因和我的回答：
“TDD让我想到它会如何失败，这让我成为了一个更好的程序员”
有了足够的经验，高度关注失败模式应该自然成为你的过程的一部分。
“应用程序需要正常工作”
这假设您能够完全测试所有内容。您首先要正确地覆盖所有可能的测试，而不是正确地编写功能代码。 “应用程序需要更好地工作”是一个更好的论点。我同意这一点，但它是理想主义的，并不足以让我尽可能多地激励。指标/轶事在这里会很棒。
“我的<库组件X>工作得很好”
我在问题中说过，我在这些案例中看到了价值，但感谢轶事。
“想想下一个开发者”
这可能是我最好的论据之一。然而，下一个开发人员很可能也不会练习TDD，因此在这种情况下它将是浪费甚至可能是负担。后门传福音就是那里的。不过，我确信TDD开发人员真的会指出它。
当你继承一个已弃用的必备方法时，你会欣赏多少项目？ RUP，有人吗？想想TDD对于下一个开发者来说意味着什么，如果TDD没有人们想象的那么大。
“重构更容易”
重构是一项与其他技能一样的技能，迭代开发当然需要这种技能。如果我认为新的设计从长远来看会节省时间，我倾向于丢弃相当数量的代码，并且感觉会丢失大量的测试。哪个更有效率？我不知道。
...
我可能会向任何新人推荐某种级别的TDD ......但是我已经遇到过几次已经在这个区域内的人的好处。我可能会开始向库中添加自动化测试。这样做之后，我可能会看到更多的价值。
我觉得单独飞行时更有用。由于周围没有任何人可以反复提出想法并且没有人来执行同行评审，因此您需要确保您的代码是可靠的。 TDD / BDD将为您提供这种保证。但TDD有点反对。其他人可能完全不同意我所说的话。
编辑：我可以补充说，如果做得对，你可以在编写测试的同时为你的软件生成规范。这是BDD的一个很好的副作用。你可以让自己看起来像超级开发人员，如果你正在制定可靠的代码和规范，所有这些都是你自己的。
动机的自我利益。
在我的情况下，唯一的开发人员转换为小企业主。我写了一些合理数量的库代码（表面上）让我的生活更轻松。很多这些例程和类都不是火箭科学，因此我可以非常肯定它们能够正常工作（至少在大多数情况下）通过查看代码，一些现场测试和调试方法来确保它们的行为方式我认为他们做到了。蛮力，如果你愿意的话。生活很好。
随着时间的推移，这个库不断增长，并在不同客户的更多项目中使用。测试变得更加耗时。特别是我（希望）修复错误和（甚至更有希望）不破坏其他东西的情况。这不仅仅是我代码中的错误。我必须小心添加功能（客户不断要求更多“东西”）或确保代码在移动到我的编译器（Delphi！），第三方代码，运行时环境或操作系统的新版本时仍然有效。
从极端的角度来看，我可以花更多的时间来审查旧代码而不是处理新的（读取：可计费的）项目。可以把它想象成软件的休止角度（在未经测试的软件崩溃之前你可以将它堆叠多高:)。
像TDD这样的技术为我提供了更经过精心设计，更全面测试（在客户获得它们之前）并且需要更少维护的方法和类。
最终，它转化为更少的时间进行维护，花更多的时间来做更有利可图，更有趣（几乎任何事情）和更重要（如家庭）的事情。
我们都是具有良好记录的开发人员。毕竟，我们都在阅读Stackoverflow。我们中的许多人都使用TDD，也许那些人有很好的记录。我被聘用是因为人们想要一个能够编写出色的测试自动化并且可以将其传授给其他人的人。当我独自工作时，我在家里的编码项目上做TDD，因为我发现如果不这样做，我会花时间做手动测试甚至调试，谁需要它。 （也许那些人只有良好的记录。我不知道。）
当谈到成为一名优秀的车手时，每个人都认为他们是“好车手”。这是所有车手都存在的认知偏见。程序员有自己的偏见。这个Agile Thoughts podcast series涵盖了开发人员如OP不做TDD的原因。播客存档还包含有关测试自动化概念的内容，例如test pyramid，以及关于什么是TDD的介绍以及为什么首先从podcast archive的第9集开始编写测试。
好了，轮流......我甚至可以自己做TDD（对于非尖峰/实验/原型代码），因为
如果我再想的话，我会更新......这是我在最后2分钟的反思中提出的。
我也是合同程序员。这是我的12 Reasons Why I Love Unit Tests。
我对TDD的最佳体验是围绕pyftpdlib项目。大部分的开发都是由原作者完成的，我做了一些小的贡献，但它本质上是一个独立的项目。该项目的测试套件非常全面，并测试了FTPd库的所有主要功能。在签入更改或发布版本之前，将检查所有测试，并且在添加新功能时，测试套件也会始终更新。
作为这种方法的结果，这是我曾经做过的唯一一个项目，它没有在新版本发布后出现showstopper错误，检查了更改，破坏了一个主要功能，等等。代码非常可靠，我在项目的整个生命周期中，很少有错误报告被打开，一直给人留下深刻的印象。我（和原作者）将这一成功的大部分归功于综合测试套件以及随意测试每个主要代码路径的能力。
从逻辑角度来看，您编写的任何代码都必须进行测试，如果没有TDD，您将自己手动测试。另一方面是pyftpdlib，错误数量和主要问题频率最差的代码是开发人员和QA手动尝试新功能的代码。由于时间紧缩或从裂缝中掉落，事情没有得到测试。旧的代码路径被遗忘，即使是最古老的稳定功能也最终会破坏，主要版本最终会失去重要的功能。手动测试对于验证和测试的一些随机化至关重要，但根据我的经验，我认为必须同时进行手动测试和精心构建的单元测试框架。在这两种方法之间，覆盖范围的差距较小，只能减少问题发生的可能性。
无论您是否是唯一的开发人员，都无关紧要。您必须从应用程序的角度来考虑它。所有应用程序都需要正常工作，所有应用程序都需要维护，所有应用程序都需要减少错误。当然，某些情况下TDD方法可能不适合您。这是截止日期非常快，没有时间进行单元测试。
无论如何，TDD不依赖于独奏或团队环境。这取决于整个应用程序。
我没有丰富的经验，但我有过看到与测试方法截然不同的经验。
在一项工作中，没有自动化测试。 “测试”包括在应用程序中四处寻找，尝试一下你头脑中的任何东西，看它是否破了。毋庸置疑，破解代码很容易到达我们的生产服务器。
在我目前的工作中，有许多自动化测试和完整的CI系统。现在，当代码被破坏时，它立即显而易见。不仅如此，但在我工作时，测试确实记录了我的代码中有哪些功能，以及尚未实现的功能。它给了我很大的信心，能够添加新功能，知道如果我打破现有的功能，它将不会被忽视。
所以，对我来说，这不仅取决于团队的规模，还取决于应用程序的规模。你能跟踪应用程序的每个部分吗？每个要求？您需要运行哪些测试以确保应用程序正常运行？如果您没有测试来证明应用程序是“正常工作”，它甚至意味着什么？
只需我0.02美元。
测试允许您自信地重构您没有破坏系统。首先编写测试允许测试定义系统的工作行为。根据定义，测试未定义的任何行为都是副产品，并且在重构时允许更改。首先编写测试也可以使设计朝着良好的方向发展。为了支持可测试性，您会发现需要解耦类，使用接口并遵循良好模式（例如，控制反转）以使代码易于测试。如果您之后编写测试，则无法确定是否已涵盖测试中系统的所有预期行为。您还发现有些东西因设计而难以测试 - 因为它很可能是在没有测试的情况下开发的 - 并且很容易吝啬或省略测试。
我一般都是单独工作，而且大多数都是做TDD的 - 我不在的地方就是我无法实现我的实践或者还没有找到一种适合我做TDD的好方法，例如使用Web界面。
TDD不是关于编写代码的测试。因此，它甚至为单个开发人员提供了许多好处。对于许多开发人员而言，编写更强大的代码是一种精神错误。例如，您多久会想到“现在这段代码怎么会失败？”在没有TDD编写代码后？对于许多开发人员来说，这个问题的答案是没有。对于TDD实践者来说，它将思维模式转变为在做某事之前检查对象或字符串是否为空，因为您正在编写测试以专门执行此操作（破坏代码）。
另一个主要原因是变化。无论何时与客户打交道，他们似乎都无法下定决心。唯一不变的是变化。 TDD帮助作为“安全网”找到可能破坏的所有其他区域。即使是小型项目，这也可以防止您在调试器中浪费宝贵的时间。
我可以继续，但我认为TDD更多的是编写代码而不是任何足以证明它作为唯一开发人员的用途。