作为一个成熟的开发者，不仅仅要有测试自己的代码的意识和习惯，更需要一套自动化的工具和方案。

单元测试当然是这个工具箱里面重要角色。但是单元测试只是验证了你自己的代码的正确性。如果还要更高层面正确性的验证我们就需要集成测试或者端到端的测试（E2E）。在 E2E 的测试工具上，pshu 选择了 Cypress。简单的讲下为什么。

Cypress方便定制

在 Cypress 的环境下，你写得测试更像测试而不是脚本

下面一点一点掰开了说。

可定制

因为现在前端的测试场景越来越复杂，传统的 Web 应用，H5应用，而H5的应用可能会跑在不同的 webview 中。所以测试工具就要选择容易定制的。

Cypress 的技术架构非常的朴素，就是一个用 CoffeScript + JavaScript + TypeScript 开发 electron 应用 + node.js 服务。

Cypress 运行的界面和和测试运行的浏览器中看到的用例的执行，全部都是 JavaScript。

而那些需要劫持的 http 的请求都是代理到 Cypress 的一个 Node.js 的代理服务上。所以整个技术栈中和前端开发人员技术栈非常的吻合，如果以后要定制的话，难度也不会很大。

在实际使用的过程中 pshu 也确实定制一些小功能，比如 cypress 对被测应用中的 iframe 是不做快照功能的( https://github.com/cypress-io/cypress/issues/1433 )，但是pshu 的被测应用会用到 iframe 如果没有快照功能的话，用例执行失败调查原因会非常的麻烦。这个功能自己动手就能简单实现出来了，这就是技术栈接近所带来的好处。

“用一个自己了解的工具是最好了，退而求其次用一个自己能够了解工具“，这就是选择 Cypress 的第一个重要原因了。当然用 headless 加其他测试框架的方式搭建出来测试框架也可以自己出去添加很多需要的功能，但是那个不叫定制了，是自制。像 pshu 这样的懒汉自然是选择一个现成的测试框架，能省则省了。

测试味

第二点，当我们开始使用 Cypress 写用例的时候，大家有的第一个疑问就是 cypress 的命令怎么都是同步，其他的 headless 对 DOM 的操作都是异步的，比如鼎鼎有名的 puppeteer ，各种操作都是返回一个 Promise。那 cypress 是如何做到用同步代码拉实现测试的。长话短说，cypress 写的测试用例文件中的指令并不是实际执行的，这项指令只是告诉 Cypress “我要做这些操作”，来描述测试的计划。

是的，这个用例程序只是一个静态计划，所以你在用例里面写了一个 if 语句，那么它只会在用例“解析”的时候根据 if 的条件，生成不同的测试计划；在用例实际测试执行时候，完全是没有 if 的逻辑在里面的。大家读到这里肯定会很疑惑，用那些 headless 库写用例的时候，有着和编程一样的能力，if-else 想来就来，代码和执行是一一对应的，多直接啊。Cypress 用例这么绕一下，着实让人费解。

其实 Cypress 这么绕一下的用例编写方式，可以督促我们写出跟地道的测试用例。一个测试用例主要结构可以用 “准备-执行-验证”（Arrage-Act-Assert） 三段式来概括，三个部分顺序表达式。这样结构地的测试用例不管是在写的时候，还是日后阅读的时候，都能清晰这个用例的用途。所以当我们在写测试用例的时候，理论上用例的结构中是不需要逻辑判断的。如果你的测试用例中使用了一些逻辑判断，很有可能你的用例可以拆分，或者你只是想写一个自动化脚本，而且不是测试用例。Cypress 这样天然的限制就好好的督促，这是测试用例不是脚本。

好了，这就是 pshu 选择 Cypress 的理由。这也只是我的选择。如果你对 Cypress 感兴趣，不妨尝试下，如果你想 pshu 多讲讲 Cypress 也可以留言告诉我。如果你觉得测试框架+headless 的方式来测试，也没有关系，技术有多样性才有意思嘛。