test: add test case for viewport with svg renderer

[hustcc]

• add test for controller with svg rendere and mock Canvas: createGraph
• test case for viewport
• add delay function, replace resolveWhenTimeout
• refactor test cases

[hustcc]

使用比较真实的环境去测试 Graph、Controller 等大的模块。当前这些单测放到集成测试目录中，有些不太对。

目前集成测试和单测之间其实没有特别明显的区别，单测不仅仅限于测试 util 纯函数，相反，当前的 static、animation 集成测试其实是可以当做是有一个特殊断言的单元测试。

[Aarebecca]

目前是通过这种方式进行断言的，感觉采用 describe/it 的单测形式，调试时并不是很方便

G6/packages/g6/__tests__/demo/static/graph-element.ts

Lines 41 to 50 in b693790

	if (expect) {
	expect(graph.getData().nodes).toEqual(data.nodes);
	expect(graph.getData().edges).toEqual(data.edges);
	expect(graph.getNodeData()).toEqual(data.nodes);
	expect(graph.getNodeData(data.nodes[0].id)).toEqual(data.nodes[0]);
	expect(graph.getNodeData(data.nodes.slice(0, 2).map((node) => node.id))).toEqual(data.nodes.slice(0, 2));
	expect(graph.getEdgeData()).toEqual(data.edges);
	expect(graph.getEdgeData(idOf(data.edges[0]))).toEqual(data.edges[0]);
	expect(graph.getEdgeData(data.edges.slice(0, 2).map(idOf))).toEqual(data.edges.slice(0, 2));
	expect(graph.getComboData()).toEqual([]);

[hustcc]

分城两部分：

一部分是截图对比测试，断言就是截图对比，可以调试，这部分会随着后续的 bugfix 不断增加。

另外一部分是对内部代码进行测试的，一般只要不增加功能，都不会怎么增加了。

现在在截图案例中去写断言，然后通过变量去区别是 dev 还是 test，不太好。

[hustcc]

要不就是这样组织：

• demos 中的每一个文件，是一个案例，全部使用 createGraph 返回一个实例
• dev 运行的时候，在 main.ts 中去组织和运行 demos
• test 运行的时候，再单独写一个 spec.ts 文件，引入 demos 中的 graph，然后进行断言

[Aarebecca]

要不就是这样组织：

• demos 中的每一个文件，是一个案例，全部使用 createGraph 返回一个实例
• dev 运行的时候，在 main.ts 中去组织和运行 demos
• test 运行的时候，再单独写一个 spec.ts 文件，引入 demos 中的 graph，然后进行断言

采用这种方式的话，就还需要区分哪些用例是用于截图，哪些是用于断言，或者为每个用例都编写 spec，工作量不小的。
我主要担心的一个点时，比如在测试 viewport 过程中，测试 setZoom 和 getZoom 在数据层面都是正确的，但是运行时实际访问可能会不正确，这种的话就需要配合截图测试才能验证

[hustcc]

所以分成两部分，一部分是 unit 测试，只不过现在使用的 mock Graph，直接使用现在真实的 Graph 测试即可；然后另外一部分就是截图测试，这部分的案例尽量和官网保持一致。

[hustcc]

看看最新的，我把提交的 viewport.spec.ts 放到 unit/runtime 中了，相当于这是属于 unit 测试的一部分，和源码目录对应。

[hustcc]

可以看这里，其实之前的单测使用的 mock，现在就改成使用真实环境测试就好了。可以简化不少代码，而且 mock 环境的过程本身后面也很难维护。