持续集成中的自动化测试
编写代码只是软件开发中的一小部分，更多的时间是花费在构建（build）和测试（test）。为了提高软件开发的效率，构建和自动化测试的自动化工具很多。其中主流的有两个：Travis CI 和 Jenkins。
持续集成是一种非常优秀的多人开发实践，指的是只要代码有变更，就自动运行构建和测试，反馈运行结果。确保符合预期以后，再将新代码"集成"到主干。
持续集成的好处在于，每次代码的小幅变更，就能看到运行结果，从而不断累积小的变更，而不是在开发周期结束时，一下子合并一大块代码 持续集成会在每次集成时提供一个几乎空白的虚拟机器，并拷贝用户提交的代码到机器本地，通过读取用户项目下的持续集成配置，自动化的安装环境和依赖，编译和测试完成后生成报告，在一段时间之后释放虚拟机器资源。
对于测试来说，接入持续集成后，我们的每一次push代码，每个Merge Request都会生成对应的测试结果，项目的其他成员可以很清楚地了解到新代码是否影响了现有的功能，在接入自动告警后，可以在代码提交阶段就快速发现错误，提升开发迭代效率。
自动化测试技术分层
- 使用静态类型(TypeScript)系统和 linter，来捕获拼写或语法之类的基本错误，实现方案通常时：
Eslint + Preitter。 - 编写有效单元测试，需要特别针对应用的某些关键行为或功能。
- 编写集成测试，以确保 web 应用各模块之间能够正常协调工作。
- 创建端到端功能测试，对关键路径进行自动化操作，而不是等最终用户来发现问题。
三种测试模式
测试开发模式
添加类似--watch参数监控代码改变，自动运行测试。
本地提交前
通过 git hook 钩子
我们可以给项目添加一个单元测试覆盖率提升的 hook，即每次 push 都会检查并更新测试覆盖率的阈值，每次提交都不能少于上一次提交，这样我们就可以持续进步、持续改进，持续提高测试覆盖率啦。
问题：通过 husky 在提交时，进行自动化测试。 选择：提交前测试，还是提交到 github 仓库后再触发测试呢？
提交代码到远程仓库时触发
通过 jenkins 或 travis ci构建自动化测试流程。
根据代码的存储位置作出以下选择：
- 自家仓库 ➡ jenkins 或 gitlab-ci
- 开源 Github.com ➡ Travis-CI
这个时候可能有同学问，如果你可以在 pre-commit 和 pre-push git hook 进行测试（如通过 Husky），为什么还要在持续集成中进行测试呢？
预提交pre-commit和预推送pre-commit钩子对于快速操作和测试非常有用。有时候，您甚至可以在 IDE 中设置一个钩子，在每次保存文件时运行快速的单元测试。但是通常您有多个测试套件，而且与单元测试不同的是，集成测试和性能测试通常需要更长的时间来运行，这对于 hook 来说是不可行的。
使用 CI 系统的另一个原因是运行合并后测试以验证多个并行合并不会引入任何问题。
总而言之，您运行的测试越多越好，CI 系统允许您运行通常由某种拉取请求挂钩和合并后测试触发的预合并测试。 所有这一切都在可控的可靠环境中进行。
为项目添加持续集成
Travis 排在第一，非常容易配置，用 Github 不用一分钟就可以配置。
- 登录你的 Github 账号。
- 创建 Travis 的 Web Hook 钩子。
- 返回 Travis，用你的 Github 凭据重新登录。
- 同步你的 Github 仓库，然后勾选允许
Push和Pull请求。
Jenkins:
- 创建一个环境（Jenkins 基线环境）
- 创建一系列 web 钩子
- 为每个工作进行配置（与 Travis 相比需要点时间）
重新运行构建
Travis：任何在 Github 具有写权限的人都可以点击“重启构建”来重新运行构建。 Jenkins：一次性配置。在一个 node 虚拟环境下安装所有必需软件，然后在预安装的环境下进行构建和测试。
构建日志
Travis：支持在 Amazon S3 中放置构建日志。 Jenkins：通过构建插件进行设置。
参考资料：https://stackoverflow.com/questions/32422264/jenkins-vs-travis-ci-which-one-would-you-use-for-a-open-source-project