ember.js - Ember 升级破坏了一项测试，而且仅限于 Safari

Question

我正在 try catch Heisenbug .

我正在将我们的项目从 Ember CLI 0.2.0 和 Ember 1.10.0 更新到 Ember CLI 0.2.3 和 Ember 1.11.1。这是一个相当轻松的过程，但我只有一个测试现在仅在 Safari (7.1.5) 中失败。它在 PhantomJS、Chrome 和 Firefox 中传递。

令人烦恼的是，只有当 Testem 启动测试运行时(即，当代码更改触发自动更新测试运行时)，测试才会失败。如果我从 Qunit Web 界面内部启动测试，它就会通过。无论测试分组如何，这两件事都是正确的。在浏览器中手动运行时，正在测试的功能运行良好。

这是一个集成测试，并验证当输入中的值发生更改时，输入会使用从服务器返回的值进行更新。在测试中，“服务器”是一个 Pretender 实例。测试本身如下所示:

test('Editing allocation cell', function() {
  visit('/district/periods');

  fillIn(SELECTORS.definitionRowInput(1,0), '100');
  triggerEvent(SELECTORS.definitionRowInput(1,0), 'focusout');
  // The triggerEvent should be tripping the focusOut event on a particular
  // Ember.Textfield subclass, which subsequently leads to a POST request to
  // the server. On Safari, however, the focusOut event isn't being called here.
  // It is called elsewhere in the app, and it works in production.
  // Things that also don't work: keyEvent(element, 'keypress', 16) (a tab), 
  // sending 'blur', sending 'focus-out'.
  // 'focus-out' also fails in Firefox, 'blur' and tab fail in all 4 envs

  andThen(function() {
    equal($(SELECTORS.definitionRowInput(1,0)).val(), '90', 'The updated input takes the return value from the server (even if it is different from input)');
    equal($(SELECTORS.gradeTotal(2)).text(), '120', 'Grade total updates with the new sum');
  });
});

注意第二个 andThen() block :通过向控件发送 focusout，我们应该提示支持组件中的代码将数据更新回服务器。其他浏览器会执行此操作 - 我在 Pretender 响应程序中放置一个 console.log() 来验证它 - 但 Safari 不会。我猜它没有正确响应 focusout 事件。

考虑到此测试在一个分支中通过，该分支仅因 Ember CLI 更新而有所不同......可能会发生什么变化来实现这一突破？

预计到达时间:我已单独回滚了本次更新中更新的所有库，但测试仍然失败。唯一有效的改变是回滚 Ember 本身。它在 1.11.0 中的中断方式与 1.11.1 相同，因此更改在 1.10.0 和 1.11.0 之间。 (这只留给我约 600 个 promise 来筛选......)

ETA2:我已将范围缩小到 1.11.0-beta.5 和 1.11.0 之间。我正在尝试使用bower link至 use local builds of ember但到目前为止，ember 构建在运行测试方面并不可靠，并且这两个标签的关系不会导致有效的二分。

Answer 1

我无法帮助您实际运行测试，但展平历史记录并不那么困难。您提到的标签之间有 49 个补丁。一串 gitcherry-pick 命令给出了我在 https://github.com/rdebath/test/tree/ember.js 上传的分支。

该分支上的每个提交(在 v1.11.0-beta.5 标记之后)都来自您提到的标记之间的“良好”路由。提交哈希值都不同(显然)，但最终的树哈希值与 v1.11.0 相同，因此这应该是 git bisect 的良好路径。

构建问题也可以避免，例如，我建议使用二等分来查找导致这些问题的补丁，并尽可能晚地git rebase -i该补丁。这应该把一个问题放在它的修复旁边；但“压缩”这些提交可能不是一个好主意，因为您希望能够将所有内容与真实的树相关联。

为了帮助选择提交列表，我使用了以下命令:

git log --graph --decorate --oneline --date-order --all

这样，“好的”路径就相当明显了。