Sinon: В противном случае выпуск 2.0

Я хотел бы создать новый веб-сайт документации, основанный на работе, которая уже есть в /docs . Я надеюсь потратить на это несколько часов во время отпуска на следующей неделе.

@mroderick Если у вас есть работа, дайте мне знать. Возможно, я смогу помочь с документами!

Обновлены флажки. Не уверен, стоит ли отмечать "Migrate sinon.sandbox", но по крайней мере PR закрыт.

@jonnyreeves : не знаю, почему мы должны удалить sinon.test . Это песочница вокруг теста, которая очищает все созданные заглушки и автоматически отслеживает после теста. Это избавляет людей от множества функций beforeEach и afterEach . Очень полезно и не имеет ничего общего с фреймворками для тестирования.

Пользователи должны увидеть простую альтернативу этому, чтобы это было удалено в пользу чего-то другого (лучшего).

Я сам никогда не использовал sinon.testCase , вероятно, потому, что его api подходит для BusterJS (где каждый тестовый пример является свойством тестового набора), а не Mocha (где каждый тест является анонимной функцией, работающей в теле тестового набора). ).

@ fatso83 Основная проблема с sinon.test заключается в том, что он полагается на синглтон sinon.config . IMHO Пользователи могут иметь гораздо больший контроль, создав (и восстановив) песочницу в хуках beofreEach и afterEach своей тестовой фреймворка.

Если мы собираемся оставить sinon.test (и sinon.testCase ) в общедоступном API; тогда нам нужно решить обе эти проблемы - хотя я уже давно пользуюсь / поддерживаю sinon, я новичок в взломе его проекта - как нам достичь консенсуса?

@jonnyreeves Хорошо, когда вы упомянули, что он полагается на sinon.config , это имело больше смысла. ИМХО явное создание и восстановление песочниц - это нормально, если мы предоставляем это в качестве альтернативы для людей, пришедших из Sinon 1 и задающихся вопросом, что же случилось с sinon.test . Итак, в документации должно быть написано что-то вроде

sinon.test

_Это устарело в версии 2 в пользу явного создания песочницы. См. link to sandbox ._

Я готов к более компактному API в версии 2, поэтому такие вещи, как typeOf , extends и sinon.test* могли бы лучше обслуживаться другими модулями NPM или другими существующими функциями.

Я думаю, что что-то вроде npm install sinon-test и var sinonTest = require('sinon-test')(config); могло бы стать достойной заменой.

: +1: для перемещения таких утилит в отдельные модули npm. Меньше кода в core

Спасибо за вклад; Я обновил обзор вверху, чтобы отразить обсуждение до сих пор (в основном убирая вопросительные знаки, делая задачи более понятными), пожалуйста, посмотрите.

Также, можем ли мы получить подобное закрытие:

• удаление sinon.log и sinon.logError (оба используются fake_server; и, вероятно, их лучше передать в качестве конфигурации этим экземплярам)
• удаление sinon.mock из 2.0

Спасибо

Я никогда не использовал sinon.testCase , однако я интенсивно использую sinon.test . Я согласен с тем, что он будет помещен в отдельную библиотеку, но просто чтобы не забыть: довольно много людей используют тестовые фреймворки, которые не поддерживают beforeEach по дизайну (например, ленту), с аргументом, что эти настройки функции приводят к связанным тестовым примерам. Мы можем доставить этим пользователям много проблем, если не будет простой замены.

Думаю, мы могли бы предложить что-то вроде этого в качестве пути миграции:

sinon.test = require('sinon-test');

@mantoni : Отличное предложение. Просто назначив неиспользуемому сейчас свойству test он избавит людей от лишних хлопот, просто включив одну дополнительную строку в их тесты. Нам просто нужно убедиться, что объект sinon не заморожен (как в Object.freeze(sinon) ) в какой-то момент ...

@jonnyreeves : что касается sinon.mock я помню, что @mroderick предлагал подождать, пока не будет выпущена let sinon.mock = require('sinon-mock') , если бы им так было угодно.

Что касается sinon.log* , я не вижу причин цепляться за них как за общедоступные функции, если бы мы могли просто предоставить их в качестве конфигурации, когда это необходимо.

WRT вычитает sinon-test , просто обратите внимание, что нам нужно разрешить потребителям предоставлять конфигурацию, то есть:

sinon.test = require('sinon-test').withConfig({ ... });

или похожие.

Только что заметил еще одно возможное изменение API при создании пакета sinon-test ; какие-нибудь мысли о том, что должно произойти с sinon.assert ? Опять же, мне это не кажется основной частью sinon API и, возможно, лучше подходит для перехода на пакет sinon-test вместе с sinon.test и sinon.testCase ?

@ fatso83 @mantoni @cjohansen; У меня есть рабочая сборка пакета sinon-test , готовая к рассмотрению - не мог бы кто-нибудь из вас инициализировать пустой репозиторий git на sinonjs/sinon-test чтобы я мог поднять PR против него, пожалуйста?

Спасибо

Это было быстро! https://github.com/sinonjs/sinon-test

@cjohansen, не могли бы вы просто

Выполнено

Спасибо, PR поднят - обратная связь приветствуется: https://github.com/sinonjs/sinon-test/pull/1

@mroderick Если у вас есть работа, дайте мне знать. Возможно, я смогу помочь с документами!

@spinningarrow, это было бы здорово. Я создал # 991, чтобы отслеживать это отдельно от остальных усилий. Я буду обновлять это в ближайшие дни с моими мыслями, и мы можем взять это оттуда.

Время от времени у нас возникают некоторые проблемы, связанные с моками. Теперь, когда @jonnyreeves проделал тяжелую работу по фактическому извлечению модуля, не имеет ли смысла переместить модуль в репо, если он является собственным? Тогда мы могли бы просто перенести все обсуждения, касающиеся моков, сюда и закрыть вопросы здесь. Это сделано в основном для облегчения административной нагрузки.

Время от времени у нас возникают некоторые проблемы, связанные с моками. Теперь, когда @jonnyreeves проделал тяжелую работу по фактическому извлечению модуля, не имеет ли смысла переместить модуль в репо, если он является собственным? Тогда мы могли бы просто перенести все обсуждения, касающиеся моков, сюда и закрыть вопросы здесь. Это сделано в основном для облегчения административной нагрузки.

Это также означало бы бремя администрирования по поддержанию синхронизации этого репозитория с инструментами разработки и т. Д.
Может быть, нам следует сначала убедиться, что у нас есть простые инструменты разработки с общим доступом? Копия: @mantoni

@mroderick @ fatso83 Хорошо, давайте посмотрим, сможем ли мы выпустить 2.0.

Я обновил обзор этой проблемы, чтобы охватить то, что я считаю всеми незавершенными миграциями (включая CJSification тестового набора, пожалуйста, если вы читаете это - помогите!) - пожалуйста, посмотрите и дайте мне знать, если вы согласны с выдающаяся работа.

Кроме того, я хотел бы достичь консенсуса по следующим вопросам:

1. Должны ли мы удалить typeOf и extend из общедоступного ( sinon. ) API или следует дождаться Sinon 3.x, который (я предполагаю) подвергнется модернизации API .
2. Должны ли мы удалить устаревшую поддержку IE / хаки из 2.0? Это _может_ упростить миграцию, поскольку мы могли бы отказаться от кода «fakeXDM» - я не смотрел внимательно, поэтому пока не могу оценить эту работу.
3. Является ли доставка нового сайта документации обязательным условием для выпуска версии 2.0? Меня беспокоит, что у него не так много тяги :)

Спасибо всем.

@jonnyreeves : Ты определенно был занят сегодня вечером. У меня впереди долгий отпуск, так что я, безусловно, мог бы помочь с выдающимися миграциями набора тестов (есть «но» ниже).

Что касается ваших очков:

1. Они должны уйти. Я думал, что это в значительной степени решено (см. Обзор выше).
2. Давайте сначала определим «устаревший IE». Версии <10 или весь пакет sinon-ie ? IE9 все еще поставлялся с какой-то странной альтернативой CORS под названием XDR. Если кто-то все еще стремится поддерживать версии IE, выпущенные до 2012 года, я думаю, они всегда могут использовать ветку 1.x. Не знаете, что вы имеете в виду под XDM? Я не уверен, для каких версий браузера требуется sinon-ie , поэтому я не могу слишком напыщенно говорить о том, что пакет не нужен. Мы должны быть уверены в последствиях.
3. Документация сейчас является проблемой, но я немного не знаю, что здесь сказать. Я мог бы начать копаться в # 991, прежде чем помогать с другими пунктами выше. Наличие места для публикации документов сделало бы жизнь лучше.

Любопытно, каков статус по этому поводу? Не похоже, что с ~ 6 месяцев назад был достигнут значительный прогресс; В настоящее время я зависим от предварительной версии по разным причинам (функционирующая поддержка символов является огромной) - я не хочу торопиться, но простоtimeline '/' пока нет временной шкалы 'было бы здорово! <3

@ELLIOTTCABLE, поскольку у нас нет финансирования, нет установленного

1. Несмотря на то, что вы видите выше "... упомянутый 8 июля 2016 г.", это означает только то, что первый комментарий в списке относится к этой дате. В последнем выпуске № 1235 это упоминалось «12 дней назад».
2. Список вопросов почти полный - в отличие от полгода назад.

Итак ... мы кое-чего достигли, но наблюдение за исправлениями ошибок в предыдущей версии, а также постоянный набор новых функций отнимают у нас много времени на обслуживание. На то, чтобы просто исследовать и написать это, в итоге ушло полчаса 😅

По сути, после просмотра списка выше остаются только две основные проблемы:

• «Перенести fake_server и друзей» (решено 90%, осталось совсем немного - см. Выше).
• Опубликуйте веб-сайт (см. № 1220: одна второстепенная, сверхлегкая вещь и одна средняя задача, которые можно взять на себя)

Я думаю, что большинство других отметок открытия выше относятся к старым выпускам IE (6-10), которые, как я уверен, не будут поддерживаться, основываясь на обсуждениях в # 1221, поэтому их можно игнорировать. Обратимся к этому сейчас.

@ sinonjs / sinon-core: предыдущий комментарий заставил меня понять, что у нас есть некоторые проблемы выше, которые мы вряд ли решим, основываясь на обсуждении в # 1221:

1. Удалить поддержку устаревшего IE / обходные пути?
2. Исправление xdomain

Не беспокойтесь, если я создам PR, чтобы просто удалить устаревшие биты IE, если мы все равно не будем их трогать? Я бы предположил, что xdomain может оказаться в исторической насыпи, поскольку это в основном был взлом, подобный CORS только для IE, так что его можно удалить?

@ fatso83 Аааа, к. Я пропустил обновленные комментарии по указанным вопросам. Я надеюсь, что обзор этого для меня был вам полезен!

Несвязанно: похоже, что частично это связано с отказом от поддержки IE6. Это прискорбно. Ну что ж, c'est la marche du progrès! знак равно

Мы в основном там, у сайта документации есть своя проблема.

Привет, ребята, что-нибудь мешает нам отметить 2.0 как «стабильный» релиз sinon и убить 1.x? :)

Думаю, мы хотели добавить номер 1297 в последнюю очередь.

ETA на этом? Я предлагаю отправить товар не позднее, чем на следующей неделе, отложив эту функцию, если она не будет реализована.

Вы, ребята, красивы. <3