如果您不熟悉 TDD，那么这里是一个很好的起点：https ://en.wikipedia.org/wiki/Test-driven_development

我很想听听您提议的范围——也许是一些可能被测试的例子。鉴于 CNCjs 作为用户和众多控制器之一之间的中间人的角色，反过来连接到不同的机器，似乎有用的测试套件需要是巨大的。
CNCjs 在连接到控制器之前几乎什么都不做，所以我认为自动化测试的第一个要求是模拟一个或多个控制器的方法。在我参与 CNCjs 的早期，我尝试使用 grbl-sim 在云构建中测试基本的 CNCjs 功能，但没有取得太大成功。我试图修复 grbl-sim（它在硬件寄存器级别模拟 AVR UART，并试图做到时序准确，这与 Linux 时序和进程切换粒度相冲突），但决定不值得我花时间。
一旦可以使用某种形式的控制器模拟，仍然会有大量的控制器状态转换和时序可能性进行建模，以便很好地测试 CNCjs。使用 5 个异步元素（机器、控制器、CNCjs 服务器、CNCjs 浏览器、用户），事情变得非常复杂。
但也许我不明白你提议的范围。

我同意完整的端到端测试几乎是不可能的，我建议对前端开发（CNCjs 浏览器）进行单元和集成测试。已经通过 Tap 对应用程序端的控制器进行了测试。

目前，如果我正在为 UI 添加功能，我必须每次都重复手动导航到 UI 中的同一位置，以查看我的更改是否产生了预期的效果。同样，也无法判断更改是否对另一个元素产生了负面影响。

可供选择的工具主要有：Karma/Mocha/Jest + Expect/Jasmine/Chai/Assert。

Jest 似乎不支持渲染单个组件，而且我个人对 Karma 比对 Mocha 更熟悉。

我在这里创建了一个分支来进行测试：https ://github.com/TobyGWilliams/cncjs/tree/Testing-Framework 。我的进步是有限的，因为我没有太多运气让 webpack 和 babel 与 Karma 配合得很好。

托比

有趣的。我可能应该为我维护的 cncjs-shopfloor-tablet 做这样的事情。它不使用 webpack 或 babel，所以也许 Karma 会更喜欢它。这对于输入数字的 RPN 计算器特别有用。这有很多可以从测试套件中受益的边缘条件，几乎没有外部依赖性。

随着复杂性的增加，拥有完整的 UI 测试方法以确保新事物不会破坏现有行为非常重要。

我可能会选择 WebDriverIO（带有 Selenium 服务器）或 Google Puppeteer 进行 UI 测试。我可能会在今年有空的时候开始。