是什么能让一个软件项目工作起来是快乐的？相反的，是什么能让一个软件项目工作起来是痛苦的？对我来说，当我觉得我能够提供真正的价值时我是最快乐的，并且我发现，团队严格遵循良好的做法有助于我来完成这一目标。特别是，当一个项目所有的开发人员都致力于做测试驱动的开发时，从根本上来说工作起来就更容易了。

一个未经测试的代码就像叠叠乐游戏一样；随着时间的推移，变化变得越来越难，最终导致整个应用程序变得不稳定、很混乱，需要我们额外的、特别的关注它。

进步的感觉

手动验证代码的工作可以是一个相对耗时的任务。例如，如果我们正在写一个Web应用程序，验证一些新的功能可能意味着做一个页面刷新。此外，让Web应用程序在一个工作状态，以便我们可以重新加载该页面，这需要足够的时间来进行编码，直到我们可以再次运行它。

TDD（Test Driven Development——测试驱动开发）使我们的工作变成很小的/可管理的模块，模块里“坏”状态下的代码也只是存在于一小段时间。这使我们在任何时间都能只专注问题的一个方面，而不必处理任何其他的复杂性。这使得软件开发更容易进行并更令人满意，并且如果单元测试失败了，更能表明我们正在取得进展。此外，单元测试可以对我们正在编写的代码有个更快的反馈。与Web应用程序的例子相比，这个没有必要打开一个Web浏览器并刷新页面，我们可以用键盘快捷键来运行测试。

理解代码

软件维护性可以说是最重要的目标，我们作为开发人员必须为此努力。当他们出现时，添加新的功能或解决问题时多么的容易。关键的区别是项目中缺乏TDD将是多么的困难和繁琐。

当我想了解一些代码（如一个类或一个函数）时，我通常使用单元测试作为文档的来源。好的单元测试应该有以下特点：简要总结一下的意图是什么，输入/输出是什么，以及什么是跟他有关系的。这使我能够很快地得到它的所有有关的要点。

相反，当没有测试时，你有责任调查一个特定的类/函数的功能是什么。你需要逐行了解代码，看看它到底是什么意思。从我所经历过的来说，没有被测试驱动的代码往往会导致过度耦合，这就需要更大的精力去集中解开。我可能还需要看到它实际上是如何在应用程序中使用的。这需要大量的时间，就不仅仅是看一套单元测试那么容易了。

诊断错误

当一个错误出现时，单元测试在诊断这个问题上起了关键的作用。例如，我们已经观察到一些特定的用户输入到Web应用程序的结果在后台的某个地方失败了，那如何才能去诊断这个呢？有了测试系统，我们就可以用跟用户相同的输入来测试这个模块，看看我们是否可以重现这个问题。我们可以在一个环境中进行孤立的测试，并且可以更直接地去解决问题的根源。

如果我们没有单元测试？在这种情况下，你的选择将是有限的几个选项，主要就是使用调试器或“printline”语句，然后反复运行整个系统来调查这个问题。这可能是一个麻烦的考验。

用安全网改变代码

当涉及到改变时，我们需要确保的一件事是，我们不打破任何现有的功能。一套全面的单元测试可以作为变化的安全网。可以让我知道我改变了什么，并出现了什么错误。

当未测试的代码库缺乏安全网，并且必须要添加某些改变时，我们需要手动验证新的变化是否是正确的，并且要验证我们没有打破任何现有的功能。如果是大型和复杂的代码那么后者实现起来将是非常困难的。

鼓励松散耦合设计

当我们写的代码没有测试，并且我们需要依靠一个数据库或外部的接口时，没有什么能真正阻止我们在代码中添加这些低级别的依赖关系。将这些职责分离成独立的组件可能并不完全是有益的。毕竟，如果我们所做的是手动测试整个系统，那么网络的结果将是相同的。

然而，当我们让测试通知设计时，这种方法的问题表现为难写/单元测试慢。如果我们正在测试驱动一些应用程序逻辑，并且在每次测试中，我们调用一个外部的接口，那么这些测试将变得缓慢和处理起来也很痛苦。我们很快发现，在测试应用程序逻辑时，将外部的调用程序调用到自己的类中和依赖注入一个测试双是比较容易的。快速单元测试意味着更快的反馈，和一个更理想的工作流程。

当代码被分割成有逻辑的/有凝聚力的组件时，每个组件正在做的任务变得更明显。在上面的示例中，当我们发现了数据库持久性中的一个错误，所有的数据库持久性调用都在一个地方，而不是分散在所有的地方。

总结

总的来说，用可测试性思维设计的系统工作起来更加的容易，并且在整个产品的寿命周期内更易于维护。软件本质上是复杂的，因此作为开发人员能够使事情变得更容易，这将是我们提供高品质的软件的一个重要组成部分。

【英文原文：https://8thlight.com/blog/chris-jordan/2016/04/13/happiness-and-tdd.html】

{测试窝原创译文，译者：亚然}

译者简介：亚然，软件测试爱好者，长期从事软件测试工作