Sinon: EcmaScript 모듈 스터 빙을 허용하도록 Node를 구성하는 방법 문서화

나는 이것을 정확하게 쓰는 것에 대해 생각하고 있었다 :)

은 "문제는"다양한 방법의 과다 있다는 것입니다 esm 사용될 수 있지만, 우리는 커버 적어도 내가 생각할 겁니다 가장 일반적인 경우는 통해해야 require 받는 플래그 node 프로세스. 여기서 구성 파일을 사용하는 방법을 구체화하기 시작했지만 환경 변수로 json 문자열을 제공 할 수도 있습니다 (코드를 사용하는 경우 옵션 해시 외에도).

안녕하세요 @ fatso83!

cjs.mutableNamespace 옵션은 기본적으로 활성화되어 있으므로 구성 할 필요가 없습니다. 스터 빙은 .js 에서는 작동하지만 .mjs .js 에서는 작동하지 않습니다. _ ( .mjs 파일이 잠겨 있으므로 esm 옵션이 없습니다) _.

@jdalton js 대 mjs 구분에 대해 알려 주셔서 감사합니다. 그게 왜이 녀석 이 작동하지 못했는지 설명합니다.

cc @ 짐-킹 -2000

최소 비용으로 단위 테스트를 작성하고 싶습니다. 솔루션이 너무 까다 롭다면 mock으로 단위 테스트를 포기하고 싶습니다. 결국, 모의 테스트는 강력한 온라인 시스템을 구축하기위한 필수 방법이 아닙니다. 그러나 최후의 수단으로 sinon이 나를 위해 "proxyrequire"(또는 이와 유사한 것)를 래핑 할 수 있습니까?

@ jim-king-2000 범위를 벗어났습니다. 내보내기를 변경할 수없는 모듈 시스템을 사용하도록 명시 적으로 선택했습니다. 그것은 불행히도 여러분이 부담해야 할 비용입니다. 모듈 로더를 래핑하여 모든 종류의 시나리오 (노드, 브라우저, 트랜스 파일러 포함 / 없음 등)에서 작동하도록 만드는 것은 너무 비용이 많이 들고이 프로젝트의 명시된 목표 와 관련

저는 sinon과 모듈 시스템의 관련성을 잘 이해하지 못합니다 (죄송합니다). 내가 필요한 것은 babel이없는 js / node 모의 단위 테스트 프레임 워크 (또는 자바 대응 물인 mockito와 같은 라이브러리)입니다. 그래서 존재합니까?

요컨대, 특정 틈새 시장에 대해 : 현재는 아님 : sob :
일반적으로 : 예, 거의 모든 프레임 워크 및 런타임 조합에 대해이를 달성하는 방법이 있습니다.

Java 용어로는 Java static 메서드를 사용하여 전체 시스템을 구현 한 다음 Mockito를 사용하여 클래스를 모의하는 것과 같습니다. 할 수 없습니다.

즉, 작업을 수행하는 데 필요한 모든 것은 *.mjs 파일의 이름을 *.js 입니다. 알려진 단점없이 테스트 가능성을 얻을 수 있기 때문에 이것은 실용적인 중간 방법처럼 보입니다.

자바의 정적 함수 모킹을 위해 powermock을 사용합니다. 그러나 나는 비교를 완전히 이해하지 못할 수도 있습니다. 그건 그렇고, 나는 자바를 좋아하지 않아 진화가 너무 느립니다. 이제 여전히 async / await를 지원하지 않습니다 .

나는 모든 곳에서 * .mjs를 사용하고, 모든 소스 코드는 mjs 파일입니다. 더 나아가 다시 바벨에 의지해야한다는 의미입니다 (추가 개발 / 런타임 작업과 지저분한 호출 스택 도입). 테스트 파일을 * .js로 다시 변경할 수만 있으면 괜찮습니다.

다른 저비용 방법을 찾을 때까지 모의 (다른 테스트는 그대로 유지됨)로 포기할 것입니다.

@ fatso83 도와 주셔서 감사합니다.

누구든지 퀴블을 시도 했습니까? 🤔

참고로, 모의 라이브러리 인 "testdouble.js"에서 Node.js ESM 지원을 구현했습니다. 것이 가능하다. 이 블로그 게시물에서 구현에 대해 썼습니다.

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

누군가가 그것을 받아들이고 싶다면 여기에서 기꺼이 도와 드리겠습니다 ..

@giltayar ESM 지원 구현을 축하합니다! 좋은 기사, btw. 우리는 항상 ESM 런타임을 준수 할 때 ES 모듈 스터 빙이 가능하지 않다고 말했지만, (위와 같이) 이것이 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를 사용할 수 있다는 것을 깨달을 때까지 quibble과 함께 일하는 것을 얻었습니다.

자바 스크립트에서 모든 패키지에 자체 문서 스타일이 있고 대부분의 경우 실제 API 문서가없는 것은 이미 충분히 어렵습니다. 그러나 테스트 라이브러리가 작동하는 방식, 라이브러리를 조롱하고 라이브러리를 조롱하기위한 모듈 로더가 작동하는 방식을 파악해야하는 것은 너무 많은 일입니다. .

다른 사람들이 "최종 사용자"프로그래머를 위해 패키지를 함께 연결하는 데 집중할 수있는 반면, Sinon에있는 그대로 집중한다고 말하는 경우 전적으로 동의합니다. 저는 저와 같은 프로그래머에게 진정한 고통이 있다는 것을 보여 드리고 싶습니다. 프로세스가 단순화되면 특히 많은 사람들이 다음 해에 ES 모듈로 이동할 경우 많은 사람들이 기뻐할 것이라고 확신합니다.

기술적 이해가 그렇게 깊지 않습니다. 제 경험에 대한 피드백이 도움이 될 것이라고 생각했습니다.

@ fatso83 왜 이것이 "명시 적으로 지원을 추가하지 마십시오"라고 확신하는지 물을 수 있습니까?

다시 반복하겠습니다. 모의 가져 오기를 처리하는 것은 Sinon의 범위를 벗어나고 전문 라이브러리에서 더 잘 처리된다는 것이 Sinon 관리자의 의견입니다.

일반적으로 모든 단일 런타임에서 모든 것을 시도하는 라이브러리를 만드는 것은 이치에 맞지 않습니다. 규모가 크고 자금이 잘 지원되는 오픈 소스 프로젝트는이를 시도합니다.

Jest에 문서화 된 솔루션이 없으며 여기에 없습니다. @giltayar의 기사를 찾을 때까지 거의 포기했습니다. 그런 안도. 나는 testdouble.js를 사용할 수 있다는 것을 깨달을 때까지 quibble과 함께 일하는 것을 얻었습니다.

다른 라이브러리는 다른 선택을합니다.

testdouble.js의 관리자는 자신의 선택을합니다. 그들은 quibble을 출판하고 도서관에 통합하기로 결정했습니다. 그들에게 좋습니다. 솔루션이 마음에 들면 반드시 사용하십시오. @searls 와

자바 스크립트에서 모든 패키지에 자체 문서 스타일이 있고 대부분의 경우 실제 API 문서가없는 것은 이미 충분히 어렵습니다. 그러나 테스트 라이브러리가 작동하는 방식, 라이브러리를 조롱하고 라이브러리를 조롱하기위한 모듈 로더가 작동하는 방식을 파악해야하는 것은 너무 많은 일입니다. .

다른 사람들이 "최종 사용자"프로그래머를 위해 패키지를 함께 연결하는 데 집중할 수있는 반면, Sinon에있는 그대로 집중한다고 말하는 경우 전적으로 동의합니다. 저는 저와 같은 프로그래머에게 진정한 고통이 있다는 것을 보여 드리고 싶습니다. 프로세스가 단순화되면 특히 많은 사람들이 다음 해에 ES 모듈로 이동할 경우 많은 사람들이 기뻐할 것이라고 확신합니다.

JavaScript 생태계의 모든 문제를 해결하기 위해 여기있는 것은 아닙니다.

10 년 이상 동안 다양한 관리자가 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/

가이드가 개선 될 수 있다고 생각되면 풀 요청을 보내주세요 👍