较旧的Firefox＆＃34;附加组件＆＃34; API有一个允许测试的内置单元测试层sdk/test。这似乎不再可用。
另外使用＆＃34; package / require＆＃34;允许的代码被分成＆＃34; js仅代码＆＃34;可以使用node.js测试的软件包新的高度结构化的javascript并不能分享这个。
我的优先事项是（从最高到最低）：
那么人们如何测试他们的WebExtensions？
答案 0 :(得分：1)
仍然可以在NodeJ中运行单元测试。
为说明这一点，让我们看一下Cliqz扩展程序，它的源代码是开放的（Github link: cliqz-oss/browser-core）。相比之下，到目前为止我看到的其他扩展，代码库很大。
换句话说，这不是一个玩具示例，而是一个实际的用例。当然，缺点是由于复杂性，很难理解测试设置的工作方式（模拟的工作方式，与构建系统的集成等）。
要了解测试的外观，请看以下示例：
很难解释模拟工作原理的细节，因为您需要深入研究构建系统。从较高的角度来看，您会注意到在测试中它使用了一个名为describeModule的函数，该函数可以对依赖项进行所有模拟。
在implementation of describeModule中，您可以看到它使用systemjs动态加载ES模块。该技巧使使用NodeJ运行单元测试成为可能。
我的工作重点是（从最高到最低）：
- 算法，“业务逻辑”，例如解析输入数据-无需API-仅JavaScript
对于此类测试，首选的上述单元测试基础结构是。对于本地开发，使用NodeJ来运行测试。
- 内部逻辑-例如后台脚本与设置等进行交互。
这没什么不同。这个想法仍然是您可以模拟依赖项，然后进行经典的单元测试。
可能需要一些工作才能允许替换依赖项。如前所述，由于本示例中的代码库必须在不同的环境（例如Firefox，Chrome，Edge，ReactNative）中运行，因此必须抽象出平台API（还包括浏览器API）。
- UI交互-我可以没有这个，但是测试起来很好
要测试UI，还有其他集成测试。我不想详细介绍，但是代码中有examples。
重要的是，集成测试不是使用NodeJ执行的，而是需要一个真实的浏览器环境（例如Firefox，Chrome）。此外，还会启动可用于模拟API调用的本地HTTP服务器。
作为附带说明，短绒非常有用，并且比较容易设置。还应考虑使用一种类型化的语言（TypeScript），尤其是当项目规模越来越大且正在使用更多的人进行处理时。
您仍然需要测试，因为静态分析将无法找到逻辑错误。但是，它有助于消除某些类型的简单错误，例如拼写错误，并且开销（修复linter错误或添加类型注释）的费用不是很高。
答案 1 :(得分：0)
查看webextension-geckodriver以获取功能测试的实例。
如果您想测试与webextension API的互动，您可以直接进行（例如，为您的扩展设置测试页面并让geckodriver访问它），或者通过{{3}使用像sinon-webextension这样的假冒}。
要单元测试算法，只需使用jest，mocha或您喜欢的任何节点单元测试框架导入函数，或将它们添加到您可以在浏览器中访问的测试页面。
webext测试的完整但旧的工作示例如下：webextension-jsdom。
使用另一个伪造的真实webextension中的测试示例：example-webextension