Sinon: 그렇지 않으면 2.0 릴리스

이미 /docs 에 있는 작업을 기반으로 새 문서 웹사이트를 만들고 싶습니다. 나는 다음 주 휴가 동안 그것에 몇 시간을 할애하기를 바라고 있습니다.

@mroderick 어딘가에 밀린 작업이 있으면 알려주세요. 문서 작업을 도와드릴 수 있습니다!

체크박스를 업데이트했습니다. "sinon.sandbox 마이그레이션"을 선택해야 하는지 확실하지 않지만 최소한 PR은 닫혀 있습니다.

@jonnyreeves : 왜 sinon.test 제거해야 하는지 잘 모르겠습니다. 이것은 생성된 스텁을 정리하고 테스트 후 자동으로 감시하는 테스트 주변의 샌드박스입니다. 이는 많은 beforeEach 및 afterEach 기능에서 사람들을 경감시킵니다. 매우 유용하며 테스트 프레임워크와 관련이 거의 없습니다.

사용자는 다른 것(더 나은 것)을 위해 이것을 제거하기 위해 이것에 대한 쉬운 대안을 볼 필요가 있습니다.

저는 sinon.testCase 직접 사용한 적이 없습니다. 아마도 해당 API가 BusterJS(각 테스트 케이스가 테스트 스위트의 속성인 경우)에 적합하고 Mocha(각 테스트가 테스트 스위트의 본문에서 실행되는 익명 함수인 경우)에 적합하기 때문일 것입니다. ).

@fatso83 sinon.test 의 주요 문제는 sinon.config 싱글톤에 의존한다는 사실입니다. IMHO 사용자는 테스트 프레임워크의 beofreEach 및 afterEach 후크에서 샌드박스를 생성(및 복원)하여 훨씬 더 많은 제어 권한을 가질 수 있습니다.

공개 API에 sinon.test (및 sinon.testCase )를 유지하려는 경우; 그런 다음 우리는 이 두 가지 문제를 모두 해결해야 합니다. sinon의 오랜 사용자/지원이지만 그의 프로젝트를 해킹하는 것은 처음입니다. 어떻게 합의에 도달해야 합니까?

@jonnyreeves 좋습니다 . sinon.config 에 의존한다고 언급했을 때 더 이해가 되었습니다. IMHO가 샌드박스를 명시적으로 생성하고 복원하는 것은 Sinon 1에서 와서 sinon.test 무슨 일이 일어났는지 궁금해하는 사람들을 위한 대안으로 이것을 제공하는 한 괜찮습니다. 따라서 문서는 다음과 같이 읽어야 합니다.

sinon.test

_이는 명시적으로 샌드박스를 생성하기 위해 버전 2에서 더 이상 사용되지 않습니다. 참조 link to sandbox ._

저는 버전 2에서 더 간결한 API를 사용하고 있으므로 typeOf , extends 및 sinon.test* 은 다른 NPM 모듈 또는 기타 기존 기능에서 더 잘 제공될 수 있습니다.

npm install sinon-test 및 var sinonTest = require('sinon-test')(config); 것이 적절한 대체품이 될 수 있다고 생각합니다.

:+1: 이와 같은 유틸리티를 별도의 npm 모듈로 이동합니다. core 에 있는 더 적은 코드

입력해 주셔서 감사합니다. 지금까지의 논의를 반영하기 위해 개요를 맨 위로 업데이트했습니다(주로 물음표 제거, 작업 명확화). 한 번 살펴보세요.

또한 다음에서 유사한 폐쇄를 얻을 수 있습니까?

• sinon.log 및 sinon.logError (둘 모두 fake_server에서 사용되며 해당 인스턴스에 구성으로 전달하는 것이 더 나을 것입니다)
• 2.0에서 sinon.mock 제거

감사 해요

내가 사용한 적이 sinon.testCase 하지만 내가 무거운 사용자입니다, sinon.test . 나는 그것이 별도의 라이브러리로가는 괜찮아,하지만 그냥 잊지 : 지원하지 않는 테스트 프레임 워크를 사용하여 꽤 많은 사람들이 beforeEach 이러한 설정이 인수 디자인에 의해 (예 : 테이프) 기능은 결합된 테스트 케이스로 이어집니다. 직접 교체가 간단하지 않으면 이러한 사용자에게 많은 문제를 일으킬 수 있습니다.

마이그레이션 경로로 다음과 같은 것을 제공할 수 있을 것 같습니다.

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

@mantoni : 좋은 제안입니다. 현재 사용되지 않는 test 속성에 할당하면 테스트에 한 줄만 추가하면 사람들이 번거로움을 덜 수 있습니다. 우리는 sinon 개체가 어떤 시점에서 고정되지 않았는지 확인해야 합니다( Object.freeze(sinon) 에서 처럼) ...

@jonnyreeves : sinon.mock 관련하여 @mroderick 이 이것을 제거하기 전에 2.0이 릴리스될 때까지 기다리 let sinon.mock = require('sinon-mock') 할 수 있습니다.

sinon.log* 와 관련하여 필요할 때 구성으로 제공할 수만 있다면 공개 기능으로 고수할 이유가 없습니다.

WRT는 sinon-test 하고 소비자가 구성을 제공할 수 있도록 허용해야 합니다. 예:

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

또는 유사.

sinon-test 패키지를 만드는 동안 또 다른 가능한 API 변경을 발견했습니다. sinon.assert 에 무슨 일이 일어나야 하는지에 대한 생각이 있습니까? 다시 말하지만 이것은 나에게 sinon API의 핵심 부분처럼 느껴지지 않으며 sinon.test 및 sinon.testCase 와 함께 sinon.test sinon-test 패키지로 마이그레이션하는 것이 더 적합할 수 있습니까?

@fatso83 @mantoni @cjohansen; 검토할 준비가 된 sinon-test 패키지의 작업 빌드가 있습니다. 이에 대해 PR을 올릴 수 있도록 sinonjs/sinon-test 에서 빈 git repo를 초기화해 주시겠습니까?

감사 해요

그것은 빨랐다! https://github.com/sinonjs/sinon-test

@cjohansen 빈 README를 밀어주시겠습니까? 현재 상태로는 PR을 올릴 수 없을 것 같습니다.

완료

감사합니다, PR 제기 - 피드백 환영: https://github.com/sinonjs/sinon-test/pull/1

@mroderick 어딘가에 밀린 작업이 있으면 알려주세요. 문서 작업을 도와드릴 수 있습니다!

@spinningarrow 대단합니다. 나는 이것을 나머지 노력과 별도로 추적하기 위해 #991을 만들었습니다. 나는 내 생각과 함께 이것을 곧 업데이트할 것이고, 우리는 거기에서 그것을 가져올 수 있습니다.

우리는 때때로 mock과 관련하여 몇 가지 문제를 겪고 있습니다. @jonnyreeves 가 실제로 모듈을 추출하는 힘든 작업을 완료

우리는 때때로 mock과 관련하여 몇 가지 문제를 겪고 있습니다. @jonnyreeves 가 실제로 모듈을 추출하는 힘든 작업을 완료

이는 또한 해당 리포지토리를 개발 도구 등과 동기화된 상태로 유지해야 하는 관리 부담을 의미합니다.
쉬운 공유 개발 도구를 먼저 설정해야 할까요? 참조: @mantoni

@mroderick @fatso83 좋습니다 . 2.0을

모든 미해결 마이그레이션으로 간주되는 사항을 다루기 위해 이 문제의 개요를 업데이트했습니다. 뛰어난 작품.

또한 다음 사항에 대한 합의를 얻고 싶습니다.

1. 공개( sinon. ) API에서 typeOf 및 extend 를 제거해야 합니까, 아니면 API의 현대화를 겪을 Sinon 3.x를 기다려야 할까요? .
2. 2.0에서 레거시 IE 지원/해킹을 제거해야 합니까? 이것은 'fakeXDM' 코드를 삭제할 수 있으므로 마이그레이션을 단순화할 수 있습니다.
3. 새 문서 사이트를 제공하는 것이 2.0 릴리스의 전제 조건입니까? 견인력이 별로 없어서 걱정입니다 :)

감사합니다.

@jonnyreeves : 오늘 밤 확실히 바쁘셨군요 😺. 나는 긴 휴가를 앞두고 있으므로 테스트 스위트의 뛰어난 마이그레이션을 확실히 도울 수 있습니다(아래에 "그러나"가 있음).

귀하의 포인트에 대해:

1. 그들은 가야합니다. 나는 이것이 거의 해결되었다고 생각했습니다(참조, 위의 개요).
2. 먼저 "레거시 IE"를 정의합시다. 버전 < 10 또는 전체 sinon-ie 패키지? IE9는 여전히 XDR이라는 이상한 CORS 대안과 함께 배송되었습니다. 2012년 이전에 출시된 IE 버전을 계속 지원하려는 사람이 있다면 항상 1.x 분기를 사용할 수 있을 것입니다. XDM이 무엇을 지칭하는지 잘 모르시겠습니까? 어떤 브라우저 버전 sinon-ie 이 필요한지 잘 모르겠으므로 패키지가 필요하지 않다고 너무 과시할 수 없습니다. 우리는 그 결과를 확신해야 합니다.
3. 문서화는 지금 당장은 골칫거리이지만 여기서 무엇을 말해야 할지 잘 모르겠습니다. 위의 다른 요점을 돕기 전에 #991을 파헤칠 수 있습니다. 문서를 푸시할 수 있는 곳이 있으면 삶이 더 나아질 것입니다.

이에 대한 상태가 궁금하십니까? ~6개월 전 이후로 많은 진전이 있었던 것 같지 않습니다. 저는 현재 여러 가지 이유로 시험판에 의존하고 있습니다(Symbol 지원 기능이 큰 역할을 함).타임라인' / '아직 타임라인이 없습니다'가 좋을 것입니다! <3

@ELLIOTCABLE 자금이 없기 때문에 정해진 일정이 없습니다. 관리자 그룹 또는 귀하와 같은 다른 자원 봉사자가 위의 목록에 대해 작업할 시간이 있을 때 진행됩니다. 즉, 조금 더 찔러보기 귀찮다면 "상태"비트에 스스로 답할 수 있다고 생각합니다 😉:

1. 위에 "... 2016년 7월 8일에 참조됨"이 표시되더라도 목록의 첫 번째 댓글이 해당 날짜의 것임을 의미합니다. 최신호 #1235에서는 이를 "12일 전"이라고 언급했습니다.
2. 문제 목록은 반년 전과 달리 거의 완전합니다.

그래서 ... 우리는 어딘가에 가고 있지만 이전 버전에 대한 버그 수정을 감독하고 새로운 기능을 지속적으로 제공하는 것은 유지 관리 시간을 많이 잡아먹습니다. 조사하고 쓰는 것만으로도 결국 30분 걸렸네요 😂

기본적으로 위의 목록을 살펴본 후에는 두 가지 주요 문제만 남아 있습니다.

• "fake_server 및 친구 마이그레이션"(90% 해결, 약간 남음 - 위 참조).
• 웹사이트 게시(#1220: 사소한 것 하나, 아주 쉬운 것 하나, 중간 작업 하나 참조)

위의 다른 확인 표시 대부분은 #1221의 논의를 기반으로 지원되지 않을 것이라고 확신하는 이전 IE 릴리스(6-10)와 관련이 있으므로 무시해도 됩니다. 지금 해결할 것입니다.

@sinonjs/sinon-core: 이전 댓글에서 #1221의 논의를 기반으로 완료할 수 없는 위의 몇 가지 문제가 있음을 알게 되었습니다.

1. 레거시 IE 지원/해결 방법을 제거하시겠습니까?
2. xdomain 고정

어쨌든 만지지 않을 경우 레거시 IE 비트를 제거하기 위해 PR을 생성해도 상관없습니까? 나는 xdomain 가 역사적 매립지로 끝날 수 있다고 가정합니다. 대부분 IE 전용 CORS와 유사한 해킹이므로 제거할 수 있습니까?

@fatso83 아하하하하 참조된 문제에 대한 업데이트된 의견을 놓쳤습니다. 이 리뷰가 도움이 되었기를 바랍니다!

관련 없음: 이것의 일부가 IE6에 대한 지원을 포기하는 것 같습니다. 운이 없었어. 아 글쎄, c'est la March du progrès! /=

우리는 기본적으로 거기에 있습니다. 문서 사이트에는 자체 문제가 있습니다.

Hey chaps - 2.0을 "안정된" sinon 릴리스로 표시하고 1.x를 죽이는 것을 방해하는 것이 있습니까? :)

마지막으로 #1297을 원했다고 생각하세요.

도착 예정 시간? 늦어도 다음 주까지는 배송하지 않고 기능 중 하나가 완료되지 않은 경우 그 기능을 연기하는 것이 좋습니다.

당신은 아름답습니다. <3