JimmyLv
commented
7 years ago power-assert 跟 jest 自带的 assertion 语句对比如何？提示消息是怎样友好？可以跟 WebStorm 结合不，直接跳到出错代码那一行？
Open EthanLin-TWer opened 7 years ago
JimmyLv
commented
7 years ago power-assert 跟 jest 自带的 assertion 语句对比如何？提示消息是怎样友好？可以跟 WebStorm 结合不，直接跳到出错代码那一行？
EthanLin-TWer
commented
7 years ago 哎呀，你这几个问题，我探索了一番，总结下我的感受：
| API | Jest | power-assert |
|---|---|---|
| 简单值类型比对 | expect(received).toBe(expected) |
assert.equal(received, expected) |
| 复杂对象类型比对 | expect(received).toEqual(expected) |
assert.deepEqual(received, expected) |
| 数组长度比对 | expect(received).toHaveLength(expected) |
assert.equal(received.length, expected) |
| 部分对象比对 | expect(received).toMatchObject(expected) |
没找到 |
API 上即便有微小的差别，我觉得也不大。部分对象比对这个事情，我感觉也是有所保留的技术，有「选择性」地仅测试比对某部分对象，这个「选择性」的算法对于测试结果有无影响，就是不太好说准的事情，比如是否存在可使测试通过但不合场景的其他对象切片？当然它换得了相对宽松的比对环境，对于一些复杂代码或大型代码的场景可能有很好的收益。但相比其潜在复杂性，我觉得它似乎是对极简测试这个理念带来了额外的负担。换句话说，测试挂了，你怎么知道是测试写错挂了，还是「部分比对」的这个逻辑挂了？测试过了，你怎么知道其他的错误组合是否也能让测试通过？
很巧我们项目就有这样的使用场景，我们的 reducer 测试返回了整个 state，不进行部分比对，测试就没法写了。
分三类：简单类型比对的提示信息、简单对象比对的提示信息，以及复杂对象比对的提示信息。
power-assert 能支持的是打印中间每一步的值，这个对于判断在获取期望值的中间是否就已经出现了空值或类型错误很有帮助。它不支持 click to see difference，在对象比对时给出的差异比对也没有 jest 直观。
在 jest 支持 click to see difference，这个比对结果就非常可视化了（我猜这也是 power-assert 尝试打印中间值希望获得的结果——过程的可视化，可似乎在复杂对象的领域表现不佳）。尽管这个可视化的理念很好，但是 click 这个动作依然不敏捷，希望双方能有更好的解决方案。
直接跳到出错代码。这个双方都不支持。静静见过什么工具支持这个嘛[Smirk]
所以回顾起来，断言过程可视化 和 断言结果差异可视化 都是很有价值的反馈方式，前者目前在复杂对象的情景下形同没用（见下图，一堆木用的信息），后者需要一次鼠标点击。API 差别不大的情况下，我觉得对象结构较简单的项目可以用 power-assert，充分利用这个可视化的断言过程比对；对象结构复杂、需求复杂的项目可以用 jest，获得相对更好的差异比对体验。
Jeff-Tian
commented
5 years ago 个人觉得对于 power-assert，应该这样用更直观：
| API | Jest | power-assert |
|---|---|---|
| 简单值类型比对 | expect(received).toBe(expected) | assert(received === expected) |
| 复杂对象类型比对 | expect(received).toEqual(expected) | assert.deepEqual(received, expected) |
| 数组长度比对 | expect(received).toHaveLength(expected) | assert(received.length === expected) |
| 部分对象比对 | expect(received).toMatchObject(expected) | assert.deepEqual({attr1: received.attr1, attr2: received.attr2}, {attr1: expected.attr1, attr2: expected.attr2}) |
当前学习重点，之一。忽然有了新的学习思路，学习新的技术，一个关键的因素是「技术的作者」。因此，这次学习路线上，会专注于列出与作者相关的学习资源：
总体路线构建
快速的 UI 构建：React
状态管理：Redux + Mobx
副作用消除：redux-saga + redux-thunk
README和实践了路由管理：react-router
Observable：RxJS
Immutable #185
类型系统：TS
哎呀，可搞死葛格了。这个类型系统，是很好滴，直接可以用来表达 Tasking 里面数据输入输出项的类型。静态检查就能避免的 bug，没必要等到运行时嘛。这个流程大概是这样，ts 文件中的类型相关的信息先被 tsc 编译成 js，然后再经过 babel 转译成 ES5 代码。不能反过来，不然 babel 就算能搞出来 js/ts 代码 tsc 识别起来难度也很大；但这样要求 tsc 支持最基本/常见的 ES6/7 特性编译。
这个东西如何用到产品代码上，与 Webpack 等工具集成？如何用到测试代码上，与 mocha/jest 等本来就需要 parser/transpiler 的 loader 结合？如何与原来就集成了 Babel 等插件的 Eslint 再集成一次？等项目上有用到这个再探索。
测试：Enzyme + power-assert + jest + sinon
「测试」话题的核心，主要有两个：测试先行还是后行，以及怎么做测试的问题。
测试先行还是后行，不强求，先行的方式就是 TDD。这个问题域实际是整个 TDD 论域的问题。下面是我对 TDD 思考的一整个系列，自知算不上特别的声音，但好歹是自己的思考，对自己的认识成长过程是有意义的。里面也给出了通往经典的链接：
怎么测，TDD 的实践问题。这部分只要查 API 就好了。对于单元测试来说，一般就是 直接测、mock 测 两部分的 API 而已。之所以选 power-assert 这个断言库，一个是因为简洁而不简单的 API，支持基本类型对比、复杂类型对象深对比；一个是因为提示信息极为友好。
构建工具与包管理：webpack 3 + npm 5 + yarn
React Native
参考资料
[wiki: ]:
[Facebook: ]: