test: add fruchterman layout test

[hustcc]

• test for fruchterman, add jest-random-mock to test layout with Randomness
• demo for fruchterman
• refactor test case for circular
• add stopLayout api

todo:

• 布局之后，拖动节点，再次调用 layout，是从原始数据来 layout，而不是中间数据来 layout。
• fruchterman nodeClusterBy 支持 function 能够指定到 data 中的属性 layout#208

[hustcc]

上次的 force 中也提及到关于 random mock，所以关于单测中使用 mock，这里一起说一下。

测试的核心是监控一切变化，让我们关注的地方不出现问题

测试理论中，单元测试是对程序中的最小粒度进行测试，通过通过功能点，用断言去判定一个代码片段的输入和输出，断言是单元测试的核心，它代表我们关注什么，所以断言不是越严格越好，而是能表达代码片段的能力。

但是，很多情况，我们进行单元测试的时候，会出现一些上下文，环境，网络等问题，导致我们写单测成本非常高，比如：

• 程序的输入是一个复杂的 class（比如 runtime 需要传入 graph）
• 连接数据库
• 需要使用浏览器测试 ui
• 网络请求
• 随机性（时间、random）

这些的解法，就是使用 mock 把一些我们不关注的地方屏蔽掉，从而大大降低单测成本。比如

• 之前写 runtime 单测，使用的一个极简的 Graph，以及空实现
• jest 中内置有 jsdom，对整个 dom 结构进行 mock，其中也有大量的空实现，比如 canvas 就是空实现（ 所以后来有 jest-canvas-mock 去弥补 jsdom 的空缺 ）
• 写一个静态的数据库服务，去断言其中执行的 sql 语句
• 使用 jest-fetch-mock 去屏蔽掉实际的网络请求，仅断言 fetch 执行的参数和 url，防止单测实际运行的机器网络问题
• 对于测试 timer 相关的能力，需要使用 data mock 将时间定住

在 G6 布局中就遇到一个特殊的地方，就是布局的随机性，其中 force 和 fruchterman 核心是通过随机 + 力来驱动布局迭代，这个里面我们关注的是整个 layout 执行的过程，参数知否传递正确，而不是其中的随机性。具体关注点：

• 随机是否是足够随机的，这个是有 Math.random 或者其他随机函数保证，我们不用管
• layout 过程中的数据处理逻辑，参数传递等逻辑

所以做法就是把 random mock 掉，换成一个非随机函数，但是生成的数据具备均匀性。所以就写了 jest-random-mock 去做这个事情。

---

至于为什么用三方 repo 而不是在 G6 中写一遍，这就是 npm 存在的原因了，能被复用就能抽成包。