Typescript 测试驱动开发 TDD (2)

测试驱动开发（TDD）实际上是一种思维方式，或者说是一种范式，应该融入到任何标准的开发流程中。这个范式从测试开始，并通过这些测试推动生产代码的进展。TDD意味着提出问题：“我如何知道我已经解决了问题？”，而不仅仅是“我如何解决问题？” 这是一个重要的观念需要理解。我们编写代码来解决问题，但我们也应该能够通过使用自动化测试来证明我们已经解决了问题。

 

测试驱动开发的基本步骤如下：

• 编写一个失败的测试。
• 运行测试以确保它失败。
• 编写代码使得测试通过。
• 运行测试以验证它现在通过了。
• 运行所有的测试，确保新代码不会破坏其他测试。
• 重复以上步骤。 

 

使用TDD真的是一种心态。有些开发者遵循这种方法，先编写测试，然后再编写代码；而其他人则先编写代码，然后再编写测试。还有一些人根本不编写测试。如果你属于最后一类人，那么希望本系列介绍的技巧能帮助你朝正确的方向入门。

 

有很多借口可以不写单元测试。比如说，“测试框架不在我们最初的计划中”，或者“它会增加20%的开发时间”，或者“这些测试已经过时了，所以我们不再运行它们”。然而，事实是，在当今这个时代，我们不能承担不写单元测试的风险。应用程序变得越来越庞大和复杂，并且需求随着时间的推移而改变。一个具备良好测试套件的应用程序可以更快地进行修改，并且对未来需求变化更具弹性，而没有测试的应用程序则无法做到这一点。这就是单元测试真正节省成本的时候。通过为您的应用程序编写单元测试，您正在为其未来提供保障，并确保任何对代码库进行的更改都不会破坏现有功能。

 

我还希望编写经得起时间考验的应用程序。我们现在编写的代码可能会在未来几年内一直处于生产环境中，这意味着有时候你需要对多年前编写的代码进行增强或修复错误。测试也可以帮助解释一段代码，以及限制变量允许范围或特定条件下某段代码将执行的情况。

 

理想情况下，我们的测试应该在持续集成（Continuous Integration，简称CI）环境中运行。这意味着一旦我们将代码提交到源代码控制系统中，一个CI服务器将提取最新版本的代码，并从头开始构建它，并以自动化方式运行所有相关的测试。拥有一套测试用例并不会真正起到帮助作用，除非它们经常被执行；而通过在每次提交时由CI服务器自动运行测试，可以确保我们所提交的代码始终能够通过所有的测试。