我是我（非常小的）公司中唯一的开发人员，我即将开始为该公司开发一个中型 ASP.NET Web 应用程序。
我正在尝试确定是否应该学习测试驱动开发 (TDD) 并在此应用程序中实现它。
我需要尽快开始开发我们的新应用程序，我担心测试。我已经编程多年，但从未做过任何单元测试。
我已经阅读了许多有关 TDD 的在线资源，但我不确定我是否会“足够好”地掌握它以使其在应用程序中有效。
【问题讨论】：
标签： .net asp.net-mvc tdd
TDD、伪TDD和准TDD。很多不同的方法。这仅取决于谁执行 TDD 的级别。也有很多优点和缺点，这又取决于您的人员。这是双刃剑哲学之一。如果你不知道自己在做什么，或者在你的团队中存在不同程度的理解，这会让你陷入困境并导致内部斗争，最终导致完全移除 TDD。 TDD 也不同于（只是编写测试）。
【讨论】：
TDD 是一种很好的做法，我对它的评价不够高。
但是，如果我处于你的位置，我现在不会太担心 TDD，而是专注于围绕你的代码进行一些好的单元测试。
当棘手的业务逻辑出现时，您总是可以稍后在项目中开始使用 TDD。
我不希望您对 TDD 有不好的体验，如果您面临交付压力并且没有使用该实践的经验，则可能会发生这种情况。
在工作中使用 TDD Katas 之前，最好先在家里尝试一些 TDD Katas 以熟悉它。
可以找到一些好的 Katas here
【讨论】：
我想我会总结和评论上面的一些 cmets：
【讨论】：
如果以务实的方式完成，它可能会带来巨大的好处。反对它的论点似乎总是花费太多时间，但众所周知，如果许多情况下故意牺牲质量可能会更加有害。
我学习 TDD 已经 3 年了，老实说，我已经看到它带来了巨大的价值，我也看到它完全是在浪费时间。
这里是每个示例...
有益：开发一个相当复杂的解决方案，具有许多依赖项和变化，并且不断发展。设计时考虑到测试并拥有一套回归的单元测试使我们能够快速适应变化并能够重构代码以提高可维护性。我们在创建单元测试时使用了 80/20 规则，并忽略了低价值的测试用例。
无益：我们（教条地）决定我们必须对 QA 能想到的每个测试用例进行自动化测试，甚至是 UI 用例。许多案例非常初级，涉及的代码非常少，非常简单。让其中许多工作正常工作需要大量的设置，并增加了测试量以维持如此多的东西，这大大减慢了我们的速度。
【讨论】：
Caleb - 我想推介一个网站，该网站旨在帮助您在家中学习 TDD。如果你没有压力，你会学得更好。只需谷歌搜索“tdd-problems”，您就会找到它。
【讨论】：
TDD 的开销会随着您获得经验而减少，并且很快就会低于不使用 TDD 进行开发的开销。
尽管一开始的开销可能很大，但由于缺乏经验，您会浪费时间以错误的方式做事。关键项目是一个冒险的地方，包括学习新开发技术所需的时间
【讨论】：
我最近也开始在所有新代码中使用 TDD。是的，起初它看起来只是在浪费时间，因为我所有的逻辑都与 Gui 耦合得太紧了，所以我无法编写任何单元测试来真正保证我的代码能做它应该做的事情。
但过了一段时间，我意识到编写单元测试是如此痛苦，因为代码写得不好。我开始以这种方式重构我的代码，这样我就可以为它编写重要的单元测试。我开始使我的方法更短，更多地使用接口，并尝试尽可能地将逻辑与 Gui 分开。
我认为在测试和验证代码之外使用单元测试的目的只是为了让你成为一个整体上更好的程序员。所以无论如何学习它是值得的。
【讨论】：
基于 TDD 的开发方法的优势，我怎么强调都不为过。当您采用 TDD 时，您的单元测试与您编写的代码一起成为一等公民，而不是为了进行单元测试而维护而不是保持最新的代码。
在 TDD 中，您将单元测试用作组件应该做什么的可执行规范。你可以通过考虑你想让你的组件做什么，然后编写测试来执行这个功能来做到这一点。由于您的代码最初没有任何此功能，因此您编写的所有新测试都会失败或变红。完成测试后，开始实现组件。逐渐地，随着您添加所需的功能，红色测试将变为绿色。好消息是，在您实现了足够的功能以使所有测试通过之后，您就知道您已经完成了预期规范的实现，并且确切地知道在哪里停止。我经常看到开发人员完成实现所需功能但没有停止的情况，而是增强组件并添加额外的功能和吸引眼球的情况，这些都不是所需规范的一部分，浪费了积极的开发时间.
一旦您完成了单元测试，就很容易在持续集成环境中进行设置。该环境将从您的存储库中签出最新代码，构建它，然后运行您的单元测试。如果发生任何回归，如果有人签入任何破坏您的单元测试的代码，您会立即知道它，而不是在它被部署到您的生产环境后才发现。为了确保新代码不会引入回归，我们在存储库上设置了登录挂钩，以确保所有提交的代码也运行了随附的测试并且它们通过了。当您有多个人在一个项目上工作时，这尤其有用，因为他们可以通过您可能使用的任何监控仪表板查看存储库是否适合在那个时间点同步到。本地化特定版本的存储库也很容易，它可以工作，让人们使用已知良好的版本，而其他人正在努力修复当前破坏您的构建的任何问题。这也可能意味着仪表板指示的任何“绿色”构建都是在推送到生产环境时很有可能不会遇到问题的构建。
许多人认为采用 TDD 意味着额外的工作和麻烦，而且会更加耗时。考虑一下，编写测试所花费的额外时间将防止正在测试的任何功能被破坏，并且您会更快地而不是更晚地发现这些中断。
使用 TDD 的另一个优点是，您将更加关注您的设计，并且与非 TDD 方法相比，它的结构和组件化要好得多。这种组件化对于能够拥有一个快速执行且不易碎的单元测试套件非常重要。
GUI 测试很困难，但并非不可能。考虑 Web-UI 测试技术，例如 Selenium、WebDriver 和 Watir，它们可以以编程方式测试 Web-UI。通过仅使用它们执行昂贵的端到端测试，也很容易滥用这些工具。更好的方法是抽象您的 UI 层，以便可以独立于您的业务逻辑对其进行单独测试。您不希望 UI 测试在数据库上进行并执行操作。
总而言之，您希望编写高效的单元测试以使使用 TDD 成为一种愉快的体验，而不是一种负担。您的测试应该是快速的，独立地测试组件，并且理想情况下应该一直运行。
我在这里描述的是一个理想的情况。您不必采用提到的每一个想法，但您可以挑选任何可行的方法来提高您的开发过程的效率。
【讨论】：
只有一个开发人员实际上是一个相当小的开发工作。即使您期望有很多屏幕，但单个编码人员仍然需要很长时间才能进入中等内容（除非他们已经疯狂地剪切和粘贴）。
我不是 TDD 的忠实拥护者，但如果你是相对较新的程序员（不到 10 年），你自己一个人并且担心质量问题，我相信它会拖慢你的速度，还可以帮助您改进工作。对于年轻的程序员来说，这迫使他们更加专注于代码的真正底层行为，并使其一步一步地工作（一个早期的常见错误是大量代码太重，然后尝试一次全部调试. 老程序员可以侥幸逃脱，年轻人通常需要一次处理较小的部分）。粉丝们经常说它极大地改变了他们的编码方式（通常使整体工作更容易）。至少你可以从它开始，如果它没有真正的帮助，以后就放弃它。
TDD 无法解决的最大问题是为 Web 应用程序获取良好的架构结构。一个你不会想在五个月内扔掉的东西。 Web 应用程序可能非常棘手，很少有人能在最初的十到十二次中做对。
【讨论】：
请注意，TDD 与测试无关；这是一个发展过程。测试不是为了取代测试功能——它定义了开发过程。
听起来您在谈论单元测试和其他自动化测试。测试很好。自动化测试很好。不要害怕犯错误。如果您考虑您的代码以及如何尽可能多地自动化测试，那么您处于一个很好的位置 - 但是收益递减存在一个截止点。 100% 自动化测试可能不具有成本效益——尤其是对于您描述的组织。
如果您真的在谈论 TDD（专家称之为 TDD），那也很好。有很多发展过程。最好记住，开发过程是框架和指南——而不是像追求一样要遵循的宗教。没有一个过程是一刀切的。做对你有意义的事，并随着你的进步而改进。开发组织中只有一个人使更改过程相当轻松。首先解决您的高风险问题，并在处理低价值问题之前为这些问题制定一些轻量级的流程。
【讨论】：
记住这一点：唯一不好的测试是你不执行的测试。
现在，您需要直接进入 TDD 吗？也许不吧。但是你绝对应该尽你所能开始单元测试。你不能很好地对 GUI 进行单元测试，这很好——把这些留给 UAT。
但是您可以在幕后执行任何类型的逻辑吗？是的，你应该测试一下。
首先尝试测试单个方法。随着您的进行，您将开始遇到痛苦，因为您的代码很可能不是为测试而设计的。这可以;重构你的代码！继续这样做，直到您可以测试您的代码。记住你必须做的事情，并在下次编写代码时第一次这样做。
经过几次迭代，您将了解需要学习的内容（实际上，您只能通过实践来学习），痛苦就会消失。当这种情况发生时，我建议您可能已经准备好研究 TDD。
【讨论】：
您是否拥有易于进行单元测试的组件？您可以将您的应用程序构建为一组可单元测试的组件吗？这确实是在 TDD 环境中工作时要考虑的心态。
很容易说“它是一个 GUI 应用程序！它不可能对我的东西进行单元测试”！这可能是一个自我实现的预言。当然，您不能轻松地对所有小部件的布局进行单元测试，但是您的程序有多少与小部件的布局相关联？您可能会阻止自己做好 TDD，因为某些方面与 GUI 小部件的布局耦合得太紧，或者与其他不容易进行单元测试的东西耦合得太紧。停下来挑战自己——真的是这样吗？我可以对我的代码进行划分和模块化，以便更好地与系统的这些部分隔离吗？这样做是否合适（单元测试的收益是否值得付出代价？）。不要仅仅因为您的软件与不可单元测试的组件相关联而接受全权委托这是不可能的。
【讨论】：
这取决于您的优先事项在哪里。如果您有兴趣进一步发展自己作为开发人员，那么 TDD 绝对值得研究，即使只是为了体验。它将帮助您重新思考编码方式，并可能因此使您成为更好的开发人员。
但这很容易被 TDD 阻碍您及时推出产品的能力所抵消。您提到您是在这家公司工作的唯一开发人员，这意味着您面临完成项目的压力。 TDD 无疑是一种很好的实践，但有时现实生活中的限制和实用性必须放在首位。
简而言之，如果您可以腾出时间，那么可以，使用 TDD。这实际上并没有那么 太多的开销，您总是可以在紧要关头跳过测试。但是，如果您真的时间紧迫，并且认为您无法在不将您的产品和工作置于风险的情况下整合它，那么没有人会因为您跳过它而责备您。纯粹主义者会不同意，但这不是一个非黑即白的世界，有时必须做出妥协才能完成任务。
【讨论】：
最好的学习方式是边做边学。如果您已经阅读了这么多内容，那么是时候深入研究了——作为一个单独的开发人员，进行单元测试可能是天赐之物，因为没有另一双眼睛可以查看您的代码。
【讨论】：
我还是一名新开发人员，并进入了一家已经在进行应用程序开发的公司。 TDD 帮助我确保新的更改不会破坏已经完成的工作，并且随着我的工作，它有助于在我添加或修改代码时进行大量的错误搜索。
我喜欢我从中学到的一切，强烈建议花时间学习 TDD。
-我的 .02
【讨论】：