Sinon: Документируйте, как настроить Node, чтобы разрешить заглушки модулей EcmaScript

Я вот подумывал написать именно это :)

«Проблема» в том, что существует множество различных способов использования esm , но мы должны хотя бы рассмотреть наиболее распространенный случай, который, как я полагаю, - это использование флага require для node процесс. Я начал подробно рассказывать, как использовать файл конфигурации здесь , но, похоже, также можно указать строку json в качестве переменной среды (в дополнение к хешу параметров при использовании кода).

Привет @ fatso83!

Параметр cjs.mutableNamespace включен по умолчанию, поэтому настройка не требуется. Заглушка будет работать с .js но не с .mjs _ (файлы .mjs заблокированы, поэтому нет параметров esm ) _.

@jdalton Спасибо, что различии js vs mjs . Это объясняет, почему этот парень не смог заставить его работать.

cc @ jim-king-2000

Хочу написать unit test с минимальными затратами. Если решение будет таким хитрым, я бы предпочел отказаться от модульного теста с помощью mock. В конце концов, имитация тестирования - не обязательный метод построения надежной онлайн-системы. Но, в крайнем случае, возможно ли, что sinon оборачивает для меня "proxyrequire" (или что-то вроде этого)?

@ jim-king-2000 Это выходит за рамки. Вы явно выбрали использование модульной системы, экспорт которой должен быть неизменяемым. К сожалению, вам придется нести такую ​​цену. Обертывание загрузчиков модулей, заставляющих их работать во всевозможных сценариях (узел, браузер, с / без транспиляторов и т. Д.), Слишком дорого обходится и на самом деле не имеет ничего общего с заявленными целями этого проекта .

Я не совсем понимаю актуальность синона и модульной системы (извините). Что мне нужно, так это фреймворк для модульного тестирования js / node (или библиотека, например, java-аналог, mockito) без babel. Итак, он существует?

Короче говоря, для вашей конкретной ниши: в настоящее время нет: sob:
В общем: да, есть способы добиться этого практически для любой комбинации фреймворков и сред выполнения.

В терминах Java это похоже на реализацию всей вашей системы с использованием методов Java static а затем попытку имитировать классы с помощью Mockito. Это невозможно.

При этом все, что вам нужно, чтобы все заработало, - это переименовать файлы *.mjs в *.js . Это похоже на прагматичный средний путь, поскольку вы получите тестируемость без каких-либо известных недостатков.

Для имитации статических функций Java мы используем powermock. Но я не могу полностью понять сравнение. Кстати, я не люблю java, она слишком медленная эволюция. Теперь он по-прежнему НЕ поддерживает async / await.

Я везде использую * .mjs, все исходники - это файлы mjs. Более того, это означает, что я должен снова прибегнуть к babel (вводя дополнительную работу разработки / времени выполнения и беспорядочный стек вызовов). Ничего страшного, если бы я мог изменить только тестовые файлы обратно на * .js.

Я собираюсь отказаться от UT с помощью mock (другие тесты не повреждены), пока не найду другие недорогие способы.

@ fatso83 Спасибо за помощь.

Кто-нибудь пробовал придраться ? 🤔

К вашему сведению, я реализовал поддержку ESM для Node.js в «testdouble.js», имитирующей библиотеке. Это возможно. Я написал о реализации в этом сообщении в блоге:

https://dev.to/giltayar/mock-all-you-want-supporting-es-modules-in-the-testdouble-js-mocking-library-3gh1

Буду рад помочь здесь, если кто-то захочет взять на себя эту задачу.

@giltayar Поздравляем с внедрением поддержки ESM! Отличная статья, кстати. Мы всегда говорили, что заглушка модуля ES невозможна в соответствии со средой выполнения ESM, но мы также говорили (как и выше), что это следует обрабатывать на уровне связывания, используя что-то вроде proxyquire, rewire или ... Quibble, что является где вы добавили поддержку :)

В моем рабочем проекте мы использовали proxyquire для удаления зависимостей из модулей ES:

proxyquire('./mylib.mjs', {doSomething: () => 'done'})

Это было бы эквивалентно в Quibble (используется TestDouble), где в статье есть пример, подобный этому, но Quibble не поддерживает частичные заглушки, поэтому они немного отличаются от того, что они делают.

await quibble.esm('./mylib.mjs', {doSomething: () => 'done'}, 'yabadabadoing') // not sure what this third param does ...

Итак, в соответствии с тем, что было сказано ранее, Sinon никогда не будет явно добавлять поддержку имитации модулей ES, так как это лучше оставить Quibble, Proxyquire, Rewire, NormalModuleReplacementPlugin (webpack) и все другие способы сделать это, что является 100% средой зависимый.

@ fatso83 Если я могу спросить, почему это такое убежденное «никогда явно не добавляйте поддержку»? Я читал это несколько раз здесь в последние дни, отчаянно ища решение для имитации кода моего модуля ES6.

Никаких решений, задокументированных в Jest, здесь нет. Я почти сдался, пока не нашел статью @giltayar. Такое облегчение. У меня что-то работало с придирками, пока я не понял, что могу просто использовать testdouble.js.

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

Я полностью согласен, если вы скажете, что сосредотачиваетесь на Sinon как есть, в то время как другие могут сосредоточиться на соединении этих пакетов вместе для программиста «конечного пользователя». Я только хочу показать, что для таких программистов, как я, есть настоящая боль, и я уверен, что многие будут счастливы, если процесс упростится, особенно если многие перейдут на модули ES в ближайшие годы.

У меня нет такого глубокого технического понимания, я просто подумал, что некоторые отзывы о моем опыте могут быть полезны

@ fatso83 Если я могу спросить, почему это такое убежденное «никогда явно не добавляйте поддержку»?

Позвольте мне повторить еще раз: специалисты по сопровождению Sinon считают, что работа с имитирующим импортом выходит за рамки Sinon и лучше решается специализированными библиотеками.

Как правило, нет смысла делать библиотеку, которая пытается делать все в каждой отдельной среде выполнения. Даже более крупные, хорошо финансируемые проекты с открытым исходным кодом не пытаются этого сделать.

Никаких решений, задокументированных в Jest, здесь нет. Я почти сдался, пока не нашел статью @giltayar. Такое облегчение. У меня что-то работало с придирками, пока я не понял, что могу просто использовать testdouble.js.

Различные библиотеки делают разный выбор.

Сопровождающие testdouble.js делают свой выбор. Они решили опубликовать придирку и интегрировать ее в свою библиотеку. Для них это хорошо. Если вам нравится их решение, то непременно воспользуйтесь им. У нас нет ничего, кроме любви и уважения к @searls и разработчикам testdouble.js.

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

Я полностью согласен, если вы скажете, что сосредотачиваетесь на Sinon как есть, в то время как другие могут сосредоточиться на соединении этих пакетов вместе для программиста «конечного пользователя». Я только хочу показать, что для таких программистов, как я, есть настоящая боль, и я уверен, что многие будут счастливы, если процесс упростится, особенно если многие перейдут на модули ES в ближайшие годы.

Мы здесь не для того, чтобы решать все проблемы экосистемы JavaScript.

Более десяти лет различные сопровождающие бесплатно предоставляют семейство библиотек Sinon. Практически вся работа, которая ушла на поддержку этих библиотек, была сделана как неоплачиваемая работа в свободное время сопровождающих. Мы сами профессионально используем JavaScript и разделяем ваше разочарование. Но у нас есть так много времени, чтобы раздавать бесплатно.

У меня нет такого глубокого технического понимания, я просто подумал, что некоторые отзывы о моем опыте могут быть полезны

Было бы полезно, если бы вы написали сообщение в блоге о своих разочарованиях, насмехающихся над зависимостями, пока не натолкнетесь на решение, которое хорошо работает для вас, и о том, как вы использовали testdouble.js для большого успеха с вашим конкретным способом загрузки JavaScript.

Если окажется, что это хороший пост в блоге, я буду рад продвигать его на sinonjs.org .

@mroderick Думаю, мне следовало сначала дать понять, что вы и сопровождающие Sinon испытываете мое высочайшее уважение!

Мы здесь не для того, чтобы решать все проблемы экосистемы JavaScript.

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

работа с имитирующим импортом выходит за рамки Sinon и лучше решается специализированными библиотеками.

Справедливо, как я уже сказал, я могу это понять, и, вероятно, у вас есть более глубокое понимание усилий, связанных с реализацией этих функций. Также API загрузчика все еще экспериментальный.

В настоящее время я работаю над небольшим инструментом CLI, который я планирую выпустить с открытым исходным кодом, как только появится рабочая версия. Если это будет сделано, я думаю написать об этом в блоге. Я все еще буду пробовать Sinon с proxyquire раньше, потому что я читал слишком много хорошего о Sinon.

Я все еще буду пробовать Sinon с proxyquire раньше, потому что я читал слишком много хорошего о Sinon.

У нас есть руководство, как это сделать: https://sinonjs.org/how-to/link-seams-commonjs/

Если вы обнаружите, что руководство можно улучшить, отправьте запрос на включение 👍