我如何学会不再担心和爱TDD

（或至少在构建时测试功能）

这些天来，在互联网上的文章和研究中几乎是一致的：测试驱动的开发（此后称为TDD）是开发人员创建一切的方式。 但是，如果您像我一样，入门就比听起来困难得多。

避免测试

大约六个月前，我在Odin Project的Ruby课程中首次被介绍给TDD。 我意识到当时的好处。 这似乎是显而易见的“最佳实践”。 但是，由于当时我感觉过重，我跳过了TDD项目，直接开始构建国际象棋游戏sans-TDD。 我很高兴“完成”了Ruby课程，因此我可以继续学习 Ruby on Rails。

当我上Rails课程时，使用的主要资源之一是Michael Hartl出色的Rails教程 。 本指南“采用一种轻量级，直观的测试方法，在方便的时候使用TDD，而不必一头雾水”（第3章，第3节）。 这是有道理的：虽然严格的TDD在公司环境中似乎是个好主意，但这种务实的方法似乎更适合大多数Web应用程序开发。 这使开发人员可以更快地工作，同时仍然可以保持良好的测试覆盖率。

不过，在构建自己的应用程序时， 我发现即使实现这种轻型的TDD也很难实现 。 首先，我将其归咎于项目太小。 其中一些涉及仅建立一个或两个模型，也许是一个表格。 编写测试甚至似乎都没有必要，因为我可以轻松地手动测试所有这些功能。

当项目变得越来越大（ 这里和这里 ）时，借口变成了时间不足。 弄清楚如何编写每个步骤的测试可能需要花费构建应用程序的时间。 如果我不打扰测试的话，我当然可以更快地完成项目。 的确如此。

不测试代码的问题是显而易见的：未经测试。 是的，您已经在本地服务器上运行了该应用程序并进行了测试，以确保满足要求，并且可以成功浏览该应用程序。 但是自动化测试的意义远不止于此-它涵盖了一些极端情况以及在您仅手动检查基本功能时通常不会遇到的情况。

潮流转向

Odin项目（Facebook的一个克隆）的最终Rails项目教会了我延迟测试的另一个主要缺点。 如您所知，如果您一直在阅读我的文章，我目前是Microverse的学生。 这意味着本文中与此相关的两件事：首先，我正在与编程合作伙伴合作（因此在讨论此项目时使用术语我们 ）； 其次，我们所有项目都需要测试。 当我们进入这个项目时，我们再次选择了测试（直到目前为止在每个项目中都如此），直到应用程序功能完成为止。

上图（您可以在网上找到多个版本）总结了我们从事较大项目的经验。 很明显，到最后，我们花了太多时间进行手动测试，并确保在进行更改时没有任何损坏。 如果我们在构建每个新功能时都进行了测试（即使在功能完成后），则可以大大减少手动测试并节省大量时间。

除了浪费手动测试时间之外，还有一个事实是我们仍然必须编写测试，因为没有测试套件就无法部署真实的应用程序。 通过等到最后编写测试，我们错过了TDD的好处，但仍然不得不花时间编写测试。

在现实世界中进行测试

尽管Facebook克隆版是本课程中我们最大的项目，但生产应用程序通常包含更多模型和功能。 随着功能列表的增长，TDD变得越来越重要和有价值。

我们最近是在第一个*合同上被雇用的，该合同是在一个已经上线的网站上工作的。 良好的测试套件对生产应用程序的价值显而易见。 只要具有良好的测试覆盖率，仅要确保团队中的每个人都正确设置了开发环境就容易得多。 然后，需要对添加的每个新功能都进行测试，以确保其正常运行，因此团队中的其他人可以快速验证该功能也适用于他们。

我认为我的测试经验通常属于新开发人员。 起初，测试似乎是在浪费时间，也不是一件容易的事。 然后，我们将其视为“必要的邪恶”，最后才意识到，如果正确实施，它可以为我们节省大量时间和痛苦。 同样，我们在编写测试时变得越熟练和自信，我们就越有可能按需使用它们。

对于所有新开发人员而言，结论是您需要直接进行测试和TDD。 即使对于小型项目而言这样做似乎很愚蠢，但当您开始构建和使用大型应用程序时，马上养成这种习惯也将会有所收获。 不必担心您的应用程序是否有效，并热爱TDD。

From: https://hackernoon.com/how-i-learned-to-stop-worrying-and-love-tdd-ea22b7b7fcaa