Js的测试

关于js的测试, 需要认真对待一下了. 杭锋推荐mocha

这里只是一个尝试

• 调试不要用console, 用debug.
• 测试用mocha.

然后剧情就翻转了

• 这里说了用tape代替mocha: https://medium.com/javascript-scene/why-i-use-tape-instead-of-mocha-so-should-you-6aa105d8eaf4
• facebook推出了: jest
• egg推荐: power-assert
  • https://eggjs.org/zh-cn/core/unittest.html

mocha还是要看一眼

• https://mochajs.org
• 然后碰上了npm网络波动, cnpm都不正常了. 过了半个小时好了.

继续原本的剧情. 阅读: 为啥我不用mocha

我们要测试啥?

• module 模块, 这个其实和接口等价了.
• component 组件
• funcition 函数

也就是说, 我们要逐个测试. 每个模块, 组件, 函数, 接口, 文件都要对应独立的单元测试.

作者不用mocha的理由:

• mocha这类工具有太多配置, 一堆一堆的配置. 这个通过看介绍就感受到了. tape不需要配置.
• 污染了全局上下文, 多了一堆诸如: describe, it, …… 等等很多全局变量/函数/对象. tape用的是包策略, 通过module引入.
• 做了一个完全不该再测试中做的事: 共享了状态, 也就是说做了上下文相关测试. tape用了内涵状态, 把状态的影响范围控制在单个测试之内.

为啥选择tape

基础的思考:

• mock和stub不该话我们很多时间, 我们应该花精力让代码模块化.
• 如果真的需要mock, 也请保持简单. 可以比stubs多一点点.
• 如果我们模块化做的, 把代码分解为简单的纯函数, 那么我们就越是可以不依赖mock
• assert应该简单, 作者只推荐使用深度相等.

测试用例应该:

• 简单描述正在测试的功能.
• 提供预期结果.
• 实际值和预期值比较.

简单的测试断言

• 更好的可读性
• 更少的代码
• 更少的维护

类似mocha, jasmine, jest这样的端到端方案更难于配合持续集成.

:) 我就是这么干的.

tap

• Test Anything Protocol (1987) , 是一种输出描述.

作者推荐的模式是比较老的, 需要babel.

• 他用了TAP, unix领域的格式化标准.

名词解释

• Spies，提供了函数调用的信息，但不会改变其行为（译者注：类似动态代理）
• Stubs，类似Spies，但是是完全替换目标函数。这可以让你随心所欲的控制函数–抛异常，返回指定结果等
• Mocks，提供了替换整个对象的能力

4个原则

• Readable 可读
• Isolated/Integrated 整体性, 比如module或者component测试
• Thorough 彻底
• Explicit 明确

5个问题

1. What is the unit under test (module, function, class, whatever)? 我在测啥?
2. What should it do? (Prose description) 应该啥样?
3. What was the actual output? 实际啥样?
4. What was the expected output? 期望啥样?
5. How do you reproduce the failure? 如何复现?