我应该使用TDD吗？

Question

我是我（非常小）公司的唯一开发人员，我即将开始为该公司开发中型ASP.NET Web应用程序。

我正在试图弄清楚我是否应该学习测试驱动开发（TDD）并在此应用程序中实现它。

我需要尽快开始开发我们的新应用程序，我担心测试。我已编程多年但从未进行任何单元测试。

我已经阅读了大量关于TDD的在线资源，但我不确定我是否会对其进行“足够好”的掌握，以使其在应用程序中有效。

Answer 1

这取决于您的优先级所在。如果您有兴趣进一步发展自己，那么TDD绝对值得研究一下。它会帮助您重新思考代码的方式，并可能因此而成为更好的开发人员。

但是，TDD会阻碍您及时将产品推出的能力，这可能很容易被超过。您提到您是该公司唯一的开发人员，这意味着您需要承担压力才能完成项目。 TDD当然是一种很好的做法，但有时必须先考虑现实生活中的限制和实用性。

简而言之，如果您可以节省时间，那么请使用TDD。它实际上并非 开销很大，你可以随时跳过测试。但如果你真的被时间束缚，并且不认为你能够在没有把你的产品和工作置于危险之中的情况下加入它，那么没有人会因为跳过它而误导你。纯粹主义者会不同意，但这不是一个黑白分明的世界，有时必须妥协才能完成任务。

Answer 2

记住这一点：唯一不好的测试是你不执行的测试。

现在，你需要直接潜入TDD吗？也许不吧。但你应该尽可能地开始单元测试。你不能很好地对GUI进行单元测试，这很好 - 除了那些UAT。

但是你可以在幕后执行任何逻辑吗？是的，你应该测试一下。

首先尝试测试单个方法。当你走的时候，你会开始痛苦，因为很可能你的代码不是为了测试而设计的。这可以;重构你的代码！继续这样做，直到您可以测试您的代码。记住你必须做的事情，并在下次编写代码时第一次这样做。

经过几次迭代，你将学到你需要学习的东西（真的，你只能通过这样做来学习），痛苦就会消失。当发生这种情况时，我建议你可能已经准备好研究TDD了。

Answer 3

我无法强调基于TDD的开发方法的优点。当您采用TDD时，您的单元测试会与您编写的代码一起成为一等公民，而不是为了进行单元测试而不是保持最新的代码。

在TDD中，您使用单元测试作为组件应该执行的操作的可执行规范。您可以通过考虑您希望组件执行的操作，然后编写测试来执行此功能。由于您的代码最初不具备任何此功能，因此您编写的所有新测试都将失败或变为红色。完成测试后，开始实现组件。渐渐地，当您添加所需的功能时，红色测试将变为绿色。好的一点是，在您实现了足够的功能以使所有测试通过之后，您就知道您已经完成了预期的规范并且确切地知道停止的位置。我经常看到开发人员已完成实现所需功能但不停止的情况，而是增强组件并添加额外的功能和眼睛，这些都不是所需规范的一部分，浪费了活跃的开发时间。

完成单元测试后，可以轻松地在持续集成环境中进行设置。此环境将检出存储库中的最新代码，构建它，然后运行单元测试。如果发生任何回归，如果有人检查任何破坏您的单元测试的代码，您就会知道它，而不是在它被部署到您的生产环境之后发现它。为了确保新代码不会引入回归，我们在我们的存储库中设置了登录挂钩，以确保所有提交的代码都运行了相应的测试并且它们通过了。当您有多个人在项目上工作时，这尤其有用，因为他们可以通过您可能使用的任何监控仪表板看到存储库是否可以在该时间点同步。也可以很容易地定位特定版本的存储库，它可以正常工作，让人们使用已知良好的版本，而其他人正在努力修复当前破坏构建的任何问题。这也可能意味着仪表板所指示的任何“绿色”构建都是一种构建，在推送到生产环境时很有可能不会遇到问题。

许多人认为采用TDD意味着额外的工作和麻烦，而且会更耗时。考虑一下，编写测试所花费的额外时间将阻止任何正在测试的功能中断，并且您将更快地找到这些中断，而不是更晚。

使用TDD的另一个优点是，您可以更加关注您的设计，并且它将比非TDD方法更好地构建和组件化。这种组件化对于能够具有快速执行且不易碎的单元测试套件非常重要。

GUI测试很困难，但并非不可能。考虑Web-UI测试技术，如Selenium，W​​ebDriver和Watir，它们可以以编程方式运行Web-UI。通过仅使用它们执行昂贵的端到端测试，也很容易滥用这些工具。一种更好的方法是抽象UI层，以便可以独立于业务逻辑单独测试它。您不希望进行UI测试并对数据库执行操作。

要重新上限，您希望编写有效的单元测试，以使TDD成为一种愉快的体验，而不是负担。您的测试应该快速，单独测试组件，理想情况下应始终运行。

我在这里描述的是一个理想的案例。您不必采用所提到的每一个想法，但您可以选择任何可以使您的开发过程更有效的工作。

Answer 4

请注意，TDD不是关于测试;这是一个发展过程。没有进行测试来替换测试功能 - 它是定义开发过程的原因。

听起来你在谈论单元测试和其他自动化测试。测试很好。自动化测试很好。不要害怕犯错误。如果您考虑您的代码以及如何尽可能自动化测试，那么您处于有利位置 - 但是收益递减会有所减少。 100％自动化测试可能不具有成本效益 - 特别是对于您描述的组织。

如果你真的在谈论TDD（专家称之为TDD），那也可能是好的。有许多开发过程。值得记住的是，开发过程是框架和指南 - 而不是像追求一样遵循的宗教。没有一个过程是一刀切的。做有意义的事情并随着你的进步而改进。在开发组织中只有一个人，使得变更过程相当轻松。首先解决您的高风险问题，并在处理低价值问题之前为这些问题制定一些轻量级流程。

Answer 5

最好的学习方法是做。如果您已经阅读了很多内容，那么现在是时候深入了解 - 作为一个开发人员，进行单元测试可能是天赐之物，因为没有另外一双眼睛可以查看您的代码。

Answer 6

我还是一名新开发人员，并且已经进入了一家应用程序开发已经开始的公司。 TDD帮助我确保新的更改不会破坏已经完成的工作，并且当我添加或修改代码时，我可以帮助完成大量的错误搜索。

我喜欢从中学到的一切，并强烈建议花时间学习TDD。

-my .02

Answer 7

只有一个开发人员实际上是一个相当小的开发工作。即使您期望大量的屏幕，单个编码器仍然需要很长时间才能进入某种媒介（除非他们在切割和粘贴时已经疯了）。

我不是TDD的忠实粉丝，但如果你是一个相对较新的程序员（不到10年）你就是你自己而且你担心质量问题，我相信它会让你失望，还可以帮助您改善工作。对于年轻的程序员来说，它迫使他们更专注于代码的真实底层行为并让它一次一步地工作（一个早期的常见错误是在大量代码中过于庞大，然后尝试一次调试所有代码老编程人员可以逃脱它，年轻人通常需要一次处理较小的部分。粉丝经常说它主要改变了他们编码的方式（通常使整体工作更容易）。至少你可以从它开始，如果它没有真正起作用的话，就放弃它。

TDD无法帮助您解决的最大问题是为Web应用程序提供良好的架构结构。一个你不想在五个月内扔掉的人。网络应用程序可能非常棘手，很少有人能够在前十或十二次内完成它。

Answer 8

我最近开始在所有新代码上使用TDD。是的，起初它看起来只是浪费时间，因为我的所有逻辑都与Gui紧密耦合，所以我无法编写任何真正可以保证我的代码能够完成应该做的单元测试。
但过了一段时间后，我意识到写单元测试是如此痛苦，因为代码编写得很糟糕。我开始以这种方式重构我的代码，所以我可以编写重要的单元测试。我开始缩短我的方法，更多地使用接口，并试图尽可能地与Gui分离逻辑。
我认为除了测试和验证代码之外使用单元测试的目的只是让你成为一个更好的程序员。无论如何，学习它的努力是值得的。

Answer 9

我想我会总结并评论一些上述评论：

1. 是TDD与设计有关。这不是关于测试。
2. 不确定QA为何参与乔治的设计阶段。听起来他们正在指定自动化测试。蒂姆指出，这是一个发展过程。
3. 凯文，你说'跳过测试'。再一次。 TDD是关于设计，它不是关于测试。好的你可以跳过设计，但完成的应用程序将是错误的并且不受支持。
4. Roshan提到，“你的组件应该做什么的可执行规范”。这意味着完全是最新的文档。当您是项目新手时，您可以非常快速地加快速度，您可以准确地看到原始开发人员的目标。并且，正如Jon所说，你可以改变代码并确保没有任何内容被破坏。

Answer 10

您是否拥有易于单元测试的组件？您可以将您的应用构建为一组可单元测试的组件吗？在TDD环境中工作时，这确实是思考的心态。

很容易说“它是一个GUI应用程序！它无法对我的东西进行单元测试”！这可以是一个自我实现的预言。当然，你不能轻易地对所有小部件的布局进行单元测试，但是你的程序有多少与你的小部件的布局有关？您可能会阻止自己做好TDD，因为某些方面与GUI小部件的布局过于紧密耦合，或者与其他不太容易组合的东西紧密耦合。停止并挑战自己 - 这是真的吗？我可以划分和模块化我的代码，以便它可以更好地与系统的这些部分隔离吗？这样做是否合适（单元测试收益是否值得花费？）。不要仅仅因为你的软件与非单稳态组件绑定而接受全权委托。

Answer 11

随着您获得经验，TDD的开销会减少，并且很快会变得低于未使用TDD开发的开销。

然而，开始的开销可能很大，因为缺乏经验，你会浪费时间做错事。一个关键项目是一个冒险的地方，包括学习新开发技术所需的时间

Answer 12

迦勒 - 我想推荐一个专门用来帮助学习TDD的网站。如果你没有承受压力，你会学得更好。只是谷歌的“tdd问题”，你会发现它。

Answer 13

如果以务实的方式完成它可能是一个巨大的好处。反对它的论点似乎总是花费太多时间，但众所周知，如果许多案例故意牺牲质量可能会更加有害。

我学习TDD已有3年了，我可以诚实地说，我看到它带来了巨大的价值，我也看到它完全是浪费时间。

以下是每个......

的示例

有益：开发一个相当复杂的解决方案，有很多依赖关系和变化，并且不断发展。设计时考虑到测试并拥有单元测试的回归套件，这使我们能够快速适应变化，并能够重构代码以提高可维护性。我们在创建单元测试时使用了80/20规则并省略了低值测试用例。

没有益处：（教条地）决定我们必须对QA可以想到的每个测试用例进行自动化测试，甚至是UI案例。许多案例都是如此简陋，涉及的代码非常简单。要使其中许多工作起作用，需要进行大量的设置并增加测试的数量以保持这么多，这会大大减缓我们的速度。

Answer 14

TDD是一个很好的练习，我不能高度谈论它。

然而，如果我在你的位置，我现在不会太担心TDD，而是专注于对你的代码进行一些好的单元测试。

您可以随时在项目中开始使用TDD，当棘手的业务逻辑出现时。

我不希望你有一个糟糕的TDD体验，如果你在交付压力下并且没有使用这种做法的经验，这可能会发生。

在工作中使用它之前，可以尝试在家中试用一些TDD Katas以熟悉它。

可以找到一些好的Katas here

Answer 15

TDD，伪TDD和准TDD。很多不同的方法。这取决于谁强制执行TDD级别。很多优点和缺点，再次取决于你的人员。这是双刃剑哲学之一。如果你不知道你正在做什么，或者你的小组内部有一个单独的理解水平，它会让你陷入困境并导致内部斗争，最终导致完全消除TDD。 TDD与（只是编写测试）不同。