28

我正试图抓住一个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()块：通过发送focusout到控件，我们应该提示支持组件中的代码将数据更新回服务器。其他浏览器会这样做——我console.log()在 Pretender 响应器中放了一个来验证它——但 Safari 没有。我猜它没有正确响应focusout事件。

考虑到这个测试通过了一个只因 Ember CLI 更新而不同的分支......为了打破这个问题，可能会发生什么变化？

ETA：我已经单独回滚了此更新中更新的所有库，并且测试继续失败。唯一似乎有效的更改是回滚 Ember 本身。它以与 1.11.1 相同的方式在 1.11.0 中中断，因此更改在 1.10.0 和 1.11.0 之间。（这只让我大约 600 次提交筛选...）

ETA2：我已将范围缩小到 1.11.0-beta.5 和 1.11.0 之间。我正在尝试使用bower 链接来使用 ember 的本地构建，但到目前为止，ember 构建在运行测试时一直不可靠，并且这两个标签的关系不是导致有效二等分的关系。

4

1 回答 1

6

我不能帮助你实际运行你的测试，但是扁平化历史并不是那么困难。您提到的标签之间有 49 个补丁。命令流git cherry-pick给出了我在https://github.com/rdebath/test/tree/ember.js上传的分支

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

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

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

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

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

于 2015-04-25T09:57:49.410 回答