我为什么喜欢 TDD

在这篇文章中，我展示了TDD（测试驱动开发）和无需测试的开发或在功能完成后编写测试（TLD）之间的日常差异。

TL;DR

• TDD 比非 TDD 方法花费的时间更少，因为它减少了花费大量时间的手动测试。
• 测试是一张安全网。在 TDD 中，我们在编码时就有了安全网，而不仅仅是在开发完成后。
• TDD 是一种帮助开发人员集中精力、循序渐进地开展工作的方法，可以减轻认知负担。
• TDD 鼓励清洁代码。
• 使用 TDD可以让生活变得更轻松，因为我们从少量代码开始，然后慢慢增加。

非 TDD 方法

无需测试的开发

在这种方法中，我们反复：

1. 选择场景进行测试。
2. 为这些场景编写代码。
3. 从外部进行测试并手动检查场景是否正常工作，例如，查看 UI 中的数据、查看 API 调用的结果以及执行 DB 查询。
4. 修复代码直到场景按计划进行。

我们什么时候检查之前的方案是否仍然有效？我猜每个开发人员检查的时间都不一样：功能开发完成时、每个方案之后，甚至代码修改次数之后。

测试最后发展

这种方法类似于无需测试的开发，只不过我们在开发该功能后编写测试以验证该功能是否正常工作。

TDD 101

总体思路是逐步编写代码。我们针对特定场景编写代码，同时始终验证其他场景是否仍然有效。此外，我们关心代码的简洁性，但这是在单独的阶段进行的。

对于每个场景，我们：

1. 编写一个代表特定场景的测试。我们运行测试，结果失败了*，因为我们没有编写任何代码来让它通过（编译错误也算失败）。
2. 编写使测试通过的最少代码。
3. 重构代码。

*如果测试没有失败，通常意味着我们在之前的迭代中编写的代码超过了最少的代码，或者测试等同于现有的测试。

TDD 与非 TDD 方法

测试时长

在非 TDD 方法中，我们通过反复重现相同的流程来手动测试代码。流程的重现可能包括：应用程序加载、登录、进入相关屏幕并按下按钮。反馈速度很慢，需要我们记住一系列操作。

在 TDD 中，我们只需按下按钮即可运行所有测试。单元测试通常需要几毫秒；集成测试通常需要几秒钟。

最终，TDD 比编写测试花费的时间更少，因为结果相同。但在编码时，我们仍然需要以某种方式进行测试，因此我们会进行手动测试。我认为 TDD 也比不进行测试的开发花费的时间更少，因为手动测试比编写测试花费的时间更多。

TDD 为我们提供了一种更简单、更快捷的方法来测试我们的代码。

测试是安全网

我们测试了几个场景，现在正在实现下一个。我们修改了代码，所以应该重新测试现有的场景。

在非 TDD 方法中，我们进行手动测试。手动测试耗时，而且是一项重复且精确的任务——并非我们人类擅长的。在最好的情况下，我们记录了所有场景；在最坏的情况下，它们只是我们脑海中的记忆。我们真正重新测试所有场景的可能性有多大？即使我们记录了所有场景，我们真的会重新测试所有场景吗？还是我们会因为这个过程漫长而重复而跳过一些场景？（我甚至会说这很无聊）。

在 TDD 中，只需按下按钮，我们就会在每次代码更改后测试所有现有场景。

专注——减少上下文切换

TDD 是一种定义工作顺序的方法。每个任务都有其对应的时间：编写测试、编写生产代码以及重构。

在非 TDD 方法中，每个人都有自己的方法论，即使他们没有意识到这一点。

专注于特定场景，三个阶段会形成一个由细小而明确的步骤组成的过程——小步走👶。这样的过程能够集中注意力，降低认知负荷。

我注意到：

• 重构部分帮助我避免在编码时进行重构。我不止一次在写代码时开始重构，结果却弄得代码混乱不堪，最终不得不放弃这些代码。😢
• 专注于特定场景有助于我在实施时忽略其他场景，从而减轻我的认知负荷。

清洁代码

在非 TDD 方法中，每个开发人员都会决定何时重构。根据我的经验，我们会将重构推迟到功能完成之后。问题是，很快我们就会因为开发过程中造成的混乱而遭受损失。

在 TDD 中，重构有专门的时间。因为它位于每个周期的末尾，所以我们在开发过程中使用更易于维护的代码。

与非 TDD 方法相比，使用 TDD 方法更有可能产生更干净的代码，但这很大程度上取决于开发人员。

在 TDD 中，代码编写速度较慢

我知道这听起来像是一个缺点，但是……

在 TDD 中，我们从少量代码开始，然后慢慢增长。在开发的每个阶段，我们的代码量都在减少：需要阅读的代码更少，需要调试的代码更少，需要浏览的代码更少 =>生活变得更轻松。😌

我希望我能够说服你尝试 TDD。欢迎联系我，我很乐意帮助你采用它。