Web Tests

针对 Web 生态系统的测试。

是什么

以代表 Web 开发者真实使用场景的方式测试 Web 功能。

为什么

在 WPT、caniuse、MDN compatibility、工具链和 polyfill 之间存在盲区。每个部分都经过充分测试，但仅考虑其自身。

这些都无法真正保证你的代码能够运行，以及能覆盖多少用户。

本项目旨在消除该盲区。

此外，还存在工具链和浏览器持续更新的担忧。没有人能保证今天能运行的功能明天也能运行。本项目也是关于哪些功能可用或已损坏的日志或差异记录。

结果

查看结果

分数以 nines 表示。每个失败/通过的测试会根据测试结果中浏览器的全球使用率进行加权。这提供了该功能在现实世界中的近似“可靠性”。

仅包含桌面浏览器，因为缺乏移动浏览器的可靠统计数据。

已测试

native *
babel
babel + webpack and core-js
babel + webpack, core-js and core-web
postcss-preset-env

欢迎提出其他工具的建议

* native 在文件和配置中被称为 pure，因为这些文件不会被工具链修改。

如何

Web Tests 是一个混乱的测试运行器。每天会随机选择一组浏览器，并以随机顺序运行。每个浏览器都会运行一组随机测试，同样以随机顺序进行。

测试失败会使某个功能在特定浏览器中的分数减少 0.01。测试通过会使分数增加 0.02。这样我们可以区分瞬时错误和真正的 bug。那些有点不稳定的测试（或测试环境）仍然应该获得足够高的分数，以表明功能正常工作。

入门

要求：make、go、最新版本的 node

克隆仓库
运行 npm install
运行 make 以构建所有内容（或 make -j <X> 进行并行构建）
运行 make scripts 仅构建工具

添加新测试

运行 web-tests-new-test -org="tc39" -id="ecma262" -section="6.1.1" -name="Undefined" -dir="6.1.1.Undefined"

参数	用途	示例
`-org`	规范主体	`tc36`、`whatwg`、...
`-id`	规范名称	`ecma262`、`dom`、`cssom`、...
`-section`	规范的部分	`6.1.1`
`-name`	人类可读的名称	`Undefined`
`-dir`	目录名称	`Undefined`

这将生成一个新测试。 Git 有助于定位创建的内容。

每个测试文件夹包含一个需要自定义的 meta.json 和一个 test.pure.js 文件。

如果生成的名称过于冗长或不清晰，您也可以更改文件夹名称。

您的实际测试位于 test.pure.js 中。所有其他 test.*.js 文件都会为您生成。

每个测试看起来像这样：

(function (cb) {
	// TODO : write a test
	cb(true);
})(callback);

每个测试要么通过，要么失败。这些测试中不会收集额外的调试信息。

所有测试都是“异步”的，完成时只需调用 callback 函数并传入 boolean 结果。

我们力求保持测试简单且简短。无需测试某个功能是否完全按照规范工作。最好测试某事物是否总体上可用。

所有测试也使用 ES3 编写。只有实际测试的功能可以是现代的。

// Testing `async/await`
(async function (cb) {
	// we still use var for ES3.
	var foo = await true;
	cb(foo);
})(callback);

它不是什么

这并非 caniuse 的替代品。本工具的结果可以反馈至 caniuse，但该项目的主要目标是测试特性。

在本地运行测试

Go 是构建测试运行器所必需的

从一个浅克隆开始：git clone --depth=1 https://github.com/mrhenry/web-tests.git

编译脚本
生成每个测试所使用的 html 文件
运行测试

make scripts
make html-tests-from-existing-sources
BROWSERSTACK_USERNAME=<your user name> BROWSERSTACK_ACCESS_KEY=<your access key> web-tests-browserstack