当我们介绍一个 系统测试的默认设置 早在 2016 年，我对 Rails 5.1 抱有很高的期望。 从理论上讲，系统测试通过实际界面驱动无头浏览器，可以让您更有信心整个机器正常工作。 而且由于它以黑盒方式运行，因此它应该对实现更改具有更强的弹性。 但我很遗憾地告诉大家，我在实践中还没有发现这些是真实的。 系统测试仍然像十年前一样缓慢、脆弱且充满假阴性。
我确信造成这种不适状态的原因有很多。 浏览器很复杂，由 JavaScript 驱动的 UI 很容易出现计时问题，并且弄清楚黑盒测试失败的原因通常非常困难。 但对我来说最重要的是，大多数时候系统测试似乎不再值得付出努力。 或者换句话说，我在让系统测试可靠地工作上浪费的时间比我从发现错误中看到的收益要多得多。
这触及了我们自动化测试的核心原因。 我们这样做是为了对变化进行快速反馈循环，我们这样做是为了捕捉回归，但最重要的是，我们这样做是为了对系统的工作充满信心。 这些都是有效的目标，但这并不意味着系统测试是实现这些目标的最佳方式。
现在我并不是提倡你抛弃所有的系统测试。你知道，可能大部分都抛弃。系统测试对于顶级冒烟测试来说效果很好。端到端测试往往不会发现领域模型或业务逻辑的问题，而是一些阻碍系统正确加载的配置或交互。尽早以低成本发现这些问题是件好事。
然而，最棘手的一点不是测试业务逻辑，模型和控制器测试做得更好、更便宜，而是测试 UI 逻辑。 这意味着测试 JavaScript。 我想说的是，我不确定我们是否已经到达自动化前沿。
让我最确信我的 UI 逻辑运行良好的方法不是系统测试，而是人工测试。 从字面上看，是在真实的浏览器中手动单击。 因为一半的时间 UI 测试不仅仅是“它是否有效”，而且是“它感觉是否正确”。 没有自动化可以告诉你这一点。
嘿今天有大约 300 多个系统测试。 我们正在进行一项重大审查，以减少这个数字。 沉没成本谬论让我们长期运行这个脆弱、笨重的套件。 是时候减少我们的损失，将系统测试减少到置信方程的一小部分，并且 拥抱系统测试的人为因素。 也许有一天我们可以将这项任务交给人工智能，但从今天开始，我认为我们最好放弃自动化。
1716054093
#系统测试失败
2024-05-17 19:29:36
