Sinon: fakeServer не работает с .respond (500) на 1.17.4

Я могу подтвердить, что это происходит на 1.17.4, но не на 1.17.3. У меня аналогичная установка с карма-синон.

Я предполагаю, что проблема в этом коммите https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793

Тег 1.17.4 был помещен в реестр npm, но я не нашел никаких следов этого тега в этом репозитории. Что случилось?

Я предполагаю, что тег еще не создан. Он был выпущен всего 3 часа назад

@mbarlock Да, наверное - тем не менее, я думаю, было бы лучше, если бы тег на GitHub был выпущен первым. По крайней мере, мы бы посмотрели и помогли с PR или что-то исправить.

Виноват. Забыл git push --tags . Спасибо за информацию об ошибке.

Я только что подтвердил, что фиксация 2cfbacd определенно привела к сбою тестов в mozilla / loop # 400.

Я применил патч от # 1031 локально, и он исправляет наши тесты.

Если 1.17.4 изменяет существующее поведение, разве это не должно быть частью нового основного выпуска? В настоящее время он считается совместимым с 1.17.3, поэтому package.json, определяющий зависимость sinon как «^ 1.17.3», получит версию 1.17.4 и, возможно, провалит тесты, которые раньше работали.

То, как работает 1.17.3, - это регресс, верно? Не стесняйтесь поправлять меня. В этом случае его следует исправить, а не поддерживать в неисправном состоянии.

ОБНОВЛЕНИЕ: это похоже на настоящую ошибку.

О, я не читал ваше первоначальное обсуждение на https://github.com/sinonjs/sinon/pull/861 @fearphage . Похоже, что это правильное поведение, хотя я думаю, что оно окажет большее влияние, чем предполагалось, учитывая, как долго ошибка существует в кодовой базе Sinon.

Учитывая это, похоже, что правильное решение с моей стороны - это изменить мои тесты, чтобы они полагались на xhr.onabort вместо xhr.onerror. Я подозреваю, что это изменение вызовет некоторое время путаницу, поскольку локально запускаемые модульные тесты не автоматически повторно загружают все зависимости, если они присутствуют в каталоге node_modules, поэтому люди узнают об этом, когда добавят новые зависимости в свои package.json (я быстро понял, потому что Travis CI выполняет установку npm с нуля для моих тестов).

Я не уверен, как поступить правильно. Может быть, добавить примечание в журнал изменений для 1.17.4, указав, что некоторые тесты, которые полагаются на «onerror», должны использовать «onabort»? (кстати, на момент этого комментария http://sinonjs.org/Changelog.txt еще не включает 1.17.4).

Я беру это обратно. Я попытался исправить свои тесты и понял, что в https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793 появилась новая ошибка. Функция onReadyStateChange теперь запускает «error» ProgressEvent вместо того, чтобы полагаться на функцию прерывания для прямого вызова onerror, если она определена. Проблема в том, что FakeXMLHttpRequest в настоящее время не имеет прослушивателя для события «ошибка».

Я создал PR https://github.com/sinonjs/sinon/pull/1042, чтобы добавить недостающий ключ error eventListener. Без этого изменения любые модульные тесты, которые проверяют, вызывается ли функция обработчика ошибок при правильном ответе сервера (например, 500), завершатся ошибкой. Дай мне знать свои мысли, @fearphage @ fatso83

При первоначальном чтении этого потока я не увидел https://github.com/sinonjs/sinon/pull/1041 , который добавляет отсутствующий ключ eventListener и дополнительный код для подтверждения порядка событий. Не стесняйтесь игнорировать мой пиар, если вы вместо этого согласитесь.

Хорошо, # 1041 (такой же, как # 1042) теперь объединен.

@overcaffeinated Относительно отсутствующего ошибкой в сценарии сборки для документов, которая помешала мне их обновить (см. https://github.com/sinonjs/sinon/issues/991#issuecomment-216651347). Извини за это. Надеюсь, мы сможем заставить его снова работать и добавить туда заметку об изменении.

Подобные вещи заставляют меня действительно хотеть выпустить 2.0, чтобы мы не вкладывали слишком много энергии в ветку 1.x.

1.7.4 привел к сбою нескольких моих тестов. Ожидаем ли мы, что 1.7.5 решит эту проблему?

К сожалению, это не исправит для всех, так как # 1031 еще не исправлен. Я постараюсь помочь этому сегодня вечером.

Спасибо за информацию, @ Standard8 !

Я исправил (сломал?) Это на основе моей интерпретации спецификации XHR. Было бы неплохо, если бы была реализация браузера, с которой можно было бы сравнить это, чтобы убедиться, что на этот раз все правильно. Нам нужен стенд для сравнения фальшивой реализации xhr от sinon с реальностью, чтобы убедиться, что события запускаются в правильном порядке и запускаются правильные события.

Есть берущие?

@fearphage хоть представляешь, как будет выглядеть такой стенд? набор ручных тестов? сложно имитировать "отключение сети" в обычных браузерах. поэтому я не совсем уверен, как это должно быть сделано.

Я предполагаю, что это было бы похоже на browserscope.org или, по крайней мере, он мог бы использовать его как бэкэнд для хранения результатов.

Хотя представьте себе http://www.acidtests.org/ для XHR

Вот несколько утилит на основе запросов, которые могут помочь:

https://httpbin.org/
http://requestb.in/

Это похоже на отличные ресурсы! Browserscope не работает, кстати.

@fearphage У меня не было времени придумать, как что-то добавить на

http://people.mozilla.org/~mbanner2/sinonXHRBrowserTest.html

Загружается в последних версиях Firefox, Chrome, IE и Safari.

@ Standard8 Я ценю это. Я использовал это, чтобы сравнить реализацию поддельного сервера sinon. Спасибо.

@fearphage @ fatso83 , не могли бы вы рассказать о текущем состоянии этой проблемы?

При беглом беглом просмотре это звучит так, как будто мы должны рассмотреть возможность возврата к функциональности v1.17.3 и предоставления выпуска v1.17.5 - даже несмотря на то, что старая функциональность была нарушена, это представляет собой критическое изменение API и, следовательно, должно быть перенесено в выпуск 2.0?

Я думаю, вы хорошо подытожили это, хотя @fearphage более подробно рассказывает об этом. Я все время теряюсь, пытаясь удержать в голове, что находится в ветке v1.17, а что в master . Я _ думаю_, что большинство проблем было исправлено в master , но я не думаю, что это справедливо для ветки v1.17 (которая не имеет таких исправлений, как # 1031 и # 1041 AFAIK). Я могу (возможно, ошибаюсь) ошибаться.

Я думаю, что наиболее прагматичным решением будет сделать то, что вы сказали:

• revert # 1017 (и связанный?) для ветки 1.17, чтобы снизить уровень шума и сохранить сетевой API таким же, отправить выпуск 1.17.5 и просто принять, что реализация менее правильна, чем в версии 2
• сохраните изменения в master и просто задокументируйте, что изменилось, в руководстве по миграции (см. # 1090).

Я просто понимаю, что здесь происходит. Лучше исправить, чем вернуться?

Самое большое изменение - когда error / onerror увольняется или нет, верно?

@fearphage Спасибо за участие! Так как я работаю довольно медленно, не могли бы вы кратко изложить в пяти строках, какие изменения API будут очевидны с точки зрения существующего конечного пользователя, когда все исправления будут применены к ветке v1.17?

В то время как большие изменения будут приемлемы для новой основной версии, все, что начинает нарушать множество тестов в 1.x, вероятно, должно быть приостановлено, но я просто не был уверен, что те исправления, которые были применены к master решит _большинство_ проблем, которые возникают у людей с 1.17.4.

Насколько я понимаю, единственное, что сломано, это то, что запросы, отличные от 200, все равно должны вызывать события error . Есть что-то еще? Я считаю, что все, что ему нужно, это исправления от мастера.

Похоже, неплохо было бы вытащить v1.7.4 из Github и NPM. Большинство людей возвращаются к нему или не могут перейти на него.

Если это все, что изменилось, я бы предложил просто включить исправления, которые вошли в master и как можно скорее отправить выпуск 1.17.5. Вы могли бы это сделать? Я уезжаю в отпуск ( Date.now() ).

Поскольку удаление версий NPM не считается очень "хорошим", я выполнил команду npm deprecate для 1.17.4. Не уверен и в удалении тега, если некоторые люди на него полагаются. Однако это другое обсуждение, и я предлагаю сосредоточиться на выпуске исправления.

Звучит как план. Я смогу добраться до него в эти выходные.

У меня есть предлагаемое решение этой проблемы, если кто-то хочет взвесить # 1102.

Если кому-то это нужно, я немного изменил тестовый файл @ Standard8, и это то, что я использовал, чтобы приблизить поддельный xhr к поведению браузера.

https://dl.dropboxusercontent.com/u/2400/tc/sinon/xhr-browser-test.htm

@ Standard8 Еще раз спасибо! :хлопок:

Согласно спецификации, событие onerror запускается только тогда, когда происходит событие сетевого уровня, такое как тайм-аут DNS или не отвечает сервер. 500 или 404 - это просто обычные HTTP-ответы, и приложение должно решить, произошла ли ошибка. https://www.w3.org/TR/XMLHttpRequest/#event -xhr-error
Спецификация, как всегда, слишком лаконична. JQuery считает, что ответы, отличные от 2xx, являются ошибками, поэтому многих людей смущает поведение XMLHttpRequest.

@ nyk0r : это примерно то, что делает исправление

@gil : это должно быть исправлено отличной работой @fearphage в # 1102, # 1108 и # 1109. Поскольку ваш тестовый пример является неполным (без проверки / подтверждения), не могли бы вы убедиться, что он действительно был исправлен кодом в текущей ветке v1.17? Если вы это сделаете, мы сможем как можно скорее отправить новый выпуск исправления.

В качестве альтернативы, @wlepinski или @mbarlock могли бы проверить, что это было исправлено в ветке v1.17 ? Просто измените зависимость sinon в package.json образом: sinon#v1.17 чтобы использовать правую ветвь непосредственно из GitHub.

Хорошо, проверено на исправление, выполнив этот тест:

"call load handler on non-2xx statuses" : function(){
  var stub = sinon.stub();
  this.xhr.addEventListener("load", stub);
  this.xhr.open("GET", "/");
  this.xhr.send();

  this.xhr.respond(500, { 'Content-Type' : 'application/json' }, JSON.stringify({}));
  assert(stub.called);
}

Это не работало с 1.17.4, но работает с последними исправлениями.

Оказывается, @fearphage уже покрыл этот тест в bf709a7f (строка 1797), но эй ...

Закрытие как исправлено.

К сожалению, у меня нет доступа к этому проекту для тестирования, сейчас я работаю в новой компании. Но я дам им знать, если они захотят обновить библиотеку. Спасибо за исправление !!