06-开始使用Jest

9.3.1　开始使用Jest

如前所述，我们将使用Jest来运行测试。可以通过命令行来运行Jest，它会执行测试，因此我们会向package.json文件添加一个脚本命令以便可以运行这个命令。代码清单9-1展示了如何向package.json添加自定义脚本。如果从GitHub克隆了这个仓库，那么这个脚本命令应该已经可以使用了。

代码清单9-1　设置自定义npm脚本（package.json）

{
    //...
    "scripts": {
    //...
    "test": "jest --coverage",  ⇽--- 运行测试，并输出测试覆盖率
    "test:w": "jest –watch --coverage",  ⇽--- 在监视模式中运行测试
  "jest": {
    "testEnvironment": "jsdom",
    "setupFiles": ["raf/polyfill", "./test/setup.js"]  ⇽--- 配置Jest；示例代码中包含了一些测试辅助和桩代码
  },
  "repository": {
    "type": "git",
    "url": "git+ssh://[email protected]/react-in-action/letters-social.git"
  },
  "author": "Mark Thomas <[email protected]>",
// ...

目前有了运行测试的命令（ npm test ），此时运行应该不会获取到任何有帮助的信息，因为还没有任何可以运行的测试（Jest应该会在终端给出相应的警告）。也可以通过npm run test:w在监视模式中运行Jest。这样就不用每次都手动运行测试了。Jest沉浸式的监视模式特别有用，它会做一些工作来只运行那些与发生更改的文件相关的测试。如果有一个大型测试集并且不想每次都运行每一个测试，这样做就很有帮助。还可以通过提供正则表达式或者文本字符串搜索来运行特定的测试。

工具很重要

在评估库时，测试库甚至整个测试有时最后才会被考虑。至少从两个原因看来这很糟糕。首先，不可用的测试库会让团队更难接受将其用于测试自己的代码，可能导致他们完全放弃测试，从而导致代码更难维护、更不稳定、更难于处理。

另一个缺点是，如果开发者或团队花费大量时间编写测试，测试工具会对时间产生巨大的影响，这可能很快就会转化为企业的损失，因为工程师将花费更长的时间完成他们需要做的工作。我目睹了这两种结果。如果测试从一开始就不被认为是最重要的事情，那么随着时间的推移，它会变得越来越困难，最后就被当作“总有一天”要干的那种事情。结果可能导致更难对代码修改有信心，因为有关功能的假设不再被测试支撑。

测试工具值得被重视的另一个原因是，如果要测试代码，那么需要牵扯大量的时间投入。这时如果有不可靠的测试或者需要花费很长时间运行的测试设置，那么最终可能损失数以天计的大量时间。这个问题没有有效的方式，但长远来看，将测试工具和设置作为头等问题来对待通常会有莫大帮助。