讲得很好。

里面提到的一点值得强调，就是，其实自动测试的难点不在于测试框架，而在于业务代码写的时候就要“心中有可测性的概念”。

比较随意的业务逻辑写法，架构不清，层级耦合，那么基本上几乎就是没法测的，用什么神仙测试框架也不管用，mock多到让人崩溃。

如果采用类似tdd的思维，倒不一定是非要先写测试再写代码，至少要在写代码的时候心里就知道这么写好测，那么写不好测，这样测试起来就轻松些。

举个例子，业务代码里使用到系统时间的时候，不要直接写Date.now()这种系统调用，而是自己先在Date.now()外面包一层自定义类，然后在业务代码里面使用自定义类。这样的话，在写测试的时候，就可以用多态的方式替换为一个假的系统时间类，就不用费劲地去mock真实的系统时间API了。
【 在 eGust (十年) 的大作中提到: 】
: 大的小的都一样啊，正常都是拿成熟的测试框架直接用啊。
: unittest 是非常成熟的，稍微新点儿的语言都直接自带了，老点儿的也都有主流的包。比如你说的 go 就不算老，直接就能 go test。像 python、ruby 这类脚本语言就算老，加个测试也就一个官方包而已。js 的话，jest 是占主导地位的，还有 mocha 也比较流行。
: 理论也很简单，就是保证每个单元都能单独正常工作，出 bug 就在相关测试里加 case。设计上就是分层，尽量相对独立，可以单独测试。不同层之间 interface 尽量稳定，必要时按照接口 mock 其它层，这样尽量保证每一层的功能稳定。很多静态语言的框架里，有时甚至专门套一
: ...................
--
FROM 123.120.160.*