这两个模块是有文档链接的，LZ 可以更新一下文章：

• gen_fsm
• gen_statem

别解决 ignore 的问题，解决同事……

各种制定标准，稳固统治地位

@chenge 忘了参数个数能不能检查了。RSpec 这个特性我就用了一段时间，后续代码都没用它。除了觉得用处有限之外，也觉得这种方式不太符合 duck typing 的本质 -- 本身定义 mock object 的行为就够了，为什么还要耦合一个类型？

Elixir 也是动态类型语言，typespec 需要依靠 Dialyzer 去做检查。

@chenge 这跟测试写没写全不是一个问题。假设 A depends on B 。你对 A 做测试，把依赖 B 用 mock 替换掉了。当然 B 也有自己的测试。一个月后你改了 B 的接口。这个时候 A 的测试显示一切正常。但程序已经无法运行了。

Java, C# 等静态语言里有严格的接口依赖，碰到这种情况还会报个编译错误。Ruby 吭都不会吭一声。当然 RSpec 有一些手段可以部分预防这一点，比如 instance_double 和 class_double 只允许你 stub 已经实例/类中已经定义了的方法，不过仅此而已了，检测不到方法参数和返回值，这两个方法提供的保障就是聊胜于无。

接口改了测试当然也要改。问题是到时候还记不记得这件事？比如你是否能够记得每次改 B 的时候都去搜一下它到底被哪些模块依赖了？最后你会发现要保障模块协同工作，还是得靠集成测试。

我一般用 mock 的情况：

1. 某个内部实现复杂和关联特别多的依赖，为了加快测试速度
2. 不是自己写的部分（第三方服务），为了提供稳定的前置条件
3. 跟别人约定好接口但还没实现的模块，为了开发解耦

其实第一点也是为了提供稳定的前置条件。相比构造 8 个 model 数据才能写点测试，一个 mock 显然更低成本（偷懒）。大量的 mock 看似解耦了，但代价是没法测到多个模块协作的情况。对 Ruby 这种 duck typing 的语言来说更是灾难。有时候模块接口都改了但测试不会报错（因为依赖全是 mock）。最后往往测试全绿但项目都跑不起来。

我觉得好的测试的标准是 “改动了软件行为测试就该挂掉” ，速度方面能够接受就行。

@FrankFang 原型链和祖先链确实有非常大的相似性。两者可以对比着学习。之前我用 JS 的 decorator 模拟过 Ruby 的 mixin 。不过实现 include 容易， prepend 就麻烦点。

class 早在 ES2015 时就有了，Node 估计支持得稍晚一点。而且 class 只是语法糖，背后机制还是基于原型链的。它的用处是提供了一个标准的类型声明和继承的写法，以后就不用造各种非官方的轮子了。

JS 相比 Ruby 更好的一个语法特性是 destructuring (解构) ，相当于弱化版的 pattern matching ，其他的貌似没啥印象深刻的。

为什么相关话题是 男人在结婚前都是忍着脾气，然后结婚后就爆发出来了么！ …… 这个相关度计算不错……

Rails 已是业内性能标杆，基本每个 web 框架都会拿它来比比