Sinon: 미래 이정표에 대한 아이디어

@sinonjs/core 핑

좋은 제안이야, 모건. 올려주셔서 감사합니다. 나는 또한 stub API가 혼란스럽다고 생각하며 귀하의 제안을 모두 좋아합니다. 다음은 몇 가지 생각입니다.

sinon.fake

여기서 불변성이 핵심이라는 데 동의합니다. 그러나 현재 스텁으로 가능한 일부 "정상적인" 사용 사례를 허용할 수 있습니다.

예를 들어, 다음을 산출하고 반환하는 유효한 사용 사례가 될 수 있습니다.

sinon.fake({
  yields: [null, 42],
  returns: true
})

우리는 의미가 있는 것과 그렇지 않은 것을 확인할 수 있습니다.

또한 callsThrough: true 를 구성으로 지원하면(모든 동작 속성과 함께 사용할 수 없음) "스파이" API 대신 새 가짜를 사용할 수도 있습니다. 이것은 Sinon-speak에서 "spy"와 "stub"이 무엇을 의미하는지 배우는 것보다 더 스스로 설명할 것입니다 😄

기본 샌드박스 사용

이 아이디어가 마음에 들긴 하지만 테스트 후 sinon.restore() 를 호출하면 다른 테스트에서 남은 일부를 되돌려 놀라운 결과 또는 이전에 작동했던 테스트 실패로 이어질 수 있습니다. 이렇게 하면 beforeEach 의 전역 샌드박스를 재설정하여 테스트 격리를 개선할 수 있습니다. 👍

샌드박스.교체

나는 이것을 많이 좋아한다. 나는 이것을 "이것을 거기에 붙이게 놔두는" 유틸리티로 이해합니다. 맞습니까?

또한 구성으로 callThrough: true를 지원하면(모든 동작 속성과 함께 사용할 수 없음) "스파이" API 대신 새로운 가짜를 사용할 수도 있습니다. 이것은 Sinon-speak에서 "spy"와 "stub"이 무엇을 의미하는지 배우는 것보다 더 스스로 설명할 것입니다 😄

그것은 우리가 spy 또는 stub 가 전혀 필요하지 않다는 것을 의미합니까?

샌드박스.교체

나는 이것을 많이 좋아한다. 나는 이것을 "이것을 거기에 붙이게 놔두는" 유틸리티로 이해합니다. 맞습니까?

네, 바로 그 아이디어였습니다. 많은 일을 하기 위해 동일한 메소드( sinon.stub )를 오버로드하는 대신 한 가지만 수행하는 명시적 메소드를 사용하십시오.

강조 표시한 대로 fake API는 현재 스파이 및 스텁으로 가능한 모든 것을 지원하지 않을 것입니다. 하지만 네, fake API는 stub 와 spy 기능을 통합할 수 있는 기회라고 생각합니다.

이 아이디어가 마음에 들긴 하지만 테스트 후 sinon.restore()를 호출하면 다른 테스트에서 남은 일부를 되돌려 놀라운 결과를 초래할 수 있으며 이전에 작동했던 테스트가 실패할 수 있습니다. 이렇게 하면 테스트 격리를 개선하기 위해 beforeEach에서 전역 샌드박스를 재설정할 수 있습니다. 👍

그것은 확실히 주요 변경 사항이며 가볍게 도입해서는 안됩니다.

fake 를 생성할 때 동작 구성을 전달하지 않으면 spy 와 동일합니다.

// ~spy, records all calls, has no behaviour
const fake = sinon.fake();

// ~stub, records all calls, returns 'apple pie'
const fake = sinon.fake({
    returns: 'apple pie'
});

그러면 아무 작업도 하지 않는 스텁을 어떻게 만들 수 있습니까?

그러면 아무 작업도 하지 않는 스텁을 어떻게 만들 수 있습니까?

귀하의 질문을 완전히 이해했는지 확신할 수 없지만...

// a fake that has no behaviour
const fake = sinon.fake();

// put it in place of an existing method
sandbox.replace(myObject, 'someMethod', fake);

아, 이제 무슨 말인지 알 것 같습니다. A fake 는 항상 stub 입니다. 당신이 ~spy, records all calls 라고 말했을 때 나는 "원래 함수로의 호출"을 이해했습니다. 그러나 fake 는 대체할 함수에 대해 알지 못합니다. 바로 sandbox.replace 가 하는 일입니다.

따라서 이를 염두에 두고 현재 spy 기능을 새로운 가짜로 접을 수 있는 또 다른 제안이 있습니다.

const fake = sinon.fake(function () {
   // Any custom function
});

주어진 함수는 가짜에 의해 호출됩니다. 이 API를 사용하면 다른 동작과 혼합할 수 없습니다. 사실, config 개체는 지정된 동작을 구현하는 함수를 만든 다음 이를 가짜에 전달합니다.

sandbox.spy(object, method) 구현은 다음과 같이 될 수 있습니다.

const original = object[method];
const fake = sinon.fake(original);
sandbox.replace(object, method, fake);

기본적으로 한줄요약 🤓

네. 일을 단순화하면 재미와 수익 💰을 위해 다시 믹싱을 시작할 수 있습니다.

그러나 fake 사용하고 더 이상 spy 및 stub 를 사용하지 않으려는 경우 이 두 가지를 그대로 두는 것이 좋습니다.

여기서 "다음" API에 대해 생각하고 있습니다. 어딘가에 대체 논리를 사용하려면 sandbox.spy 가 필요합니다. 내가 이해하기로는 이전 버전과 호환되어야 합니다. 그러면 stub 구현이 더 이상 사용되지 않을 수 있습니다.

어딘가에 교체 논리를 사용하려면 sandbox.spy가 필요합니다. 내가 이해하기로는 이전 버전과 호환되어야 합니다. 그러면 스텁 구현이 더 이상 사용되지 않을 수 있습니다.

팔로우하고 있는지 잘 모르겠습니다. 자세히 설명해 주시겠습니까?

확신하는. 귀하의 제안을 이해하는 한 귀하는 지나치게 복잡한 stub API를 대체하기를 원합니다. 스텁이 현재 구현되는 방식은 동작을 구현하는 함수로 spy 를 만드는 것입니다. 내가 제안하는 것은 fake API를 사용하여 동일한 작업을 수행하고 내부적으로 spy 를 생성하는 것입니다. 그러나 우리는 연결을 제거하고 싶기 때문에 더 이상 동작을 반환하지 않습니다. . 우리는 그냥 스파이를 반환합니다. 이것은 fake 구현을 stub 의 대안으로 만들고 반환된 함수는 현재 모든 Sinon API와 호환됩니다. 그것이 의미가 있습니까? 아니면 내가 뭔가를 놓치고 있습니까?

좋아요, 우리도 비슷한 이해를 하고 있는 것 같아요 👍

다시 반복하자면, 우리가 뭔가를 놓친 경우를 대비하여 다른 기여자가 동일한 이해를 가질 수 있도록 합니다.

TL;DR

• 모든 교체 는 새로운 유틸리티로 수행됩니다: sandbox.replace (현재 stub 에 있음)
• sinon 에는 sinon.reset 및 sinon.restore 를 허용하는 기본 샌드박스가 있습니다(이를 병합해야 합니까?)
• sinon.fake — 모든 호출을 기록하는 함수에 대한 변경 불가능하고 프로그래밍 가능한 대체
• sinon.spy
• sinon.stub

// effectively a spy that has no target
const fake = sinon.fake()

// spy on a function
const fake = sinon.fake(console.log);
const fake = sinon.fake(function() { return 'apple pie'; });

// a shorthand construction of fake with behaviour
const fake = sinon.fake({
    returns: 'apple pie'
});

// replacing an existing function with a fake
var fakeLog = sinon.fake();
sandbox.replace(console, 'log', fakeLog);

이 상태에서 제안은 Function 처리합니다. 함수가 아닌 속성과 접근자에 대해 무엇을 해야 하는지 고려해야 합니다. 최소한 정상적인 교체만 허용하도록 sandbox.replace 을 제한할 수 있는지 확인해야 합니다.

이것은 sinon.stub() 및 sinon.spy() 둘 다 앞으로 더 이상 사용되지 않고 sinon.fake() 를 위해 내부적으로 다시 실행된다는 것을 의미합니까? 그렇다면 본질적으로 TestDouble의 생각 을 향해 나아가고 있습니다. IMHO가 반드시 나쁜 것은 아니지만, 많은 사람들이 sinon.fake() 에 대해 모든 Sinon API 호출을 대체해야 한다는 것을 알게 되면 다른 라이브러리를 사용하는 것이 좋습니다(비록 즉, Sinon의 API에 대한 기존 지식을 모두 잃게 됩니다.

이것은 sinon.stub() 및 sinon.spy() 둘 다 미래에 더 이상 사용되지 않고 sinon.fake()를 위해 사용됨을 의미합니까, 아니면 내부적으로 다시 실행합니까? 그렇다면 우리는 본질적으로 TestDouble의 생각을 향해 나아가고 있습니다.

좀 겹치는 것 같아요. 이 제안에 대한 나의 주요 동기는 불변 동작을 가진 가짜 함수를 갖는 것입니다.

IMHO가 반드시 나쁜 것은 아니지만 많은 사람들이 sinon.fake()에 대한 모든 Sinon API 호출을 어쨌든 교체해야 한다는 것을 알게 되면 다른 라이브러리를 사용할 수도 있다는 점을 고려해 볼 가치가 있습니다. 이는 Sinon의 API에 대한 기존 지식을 모두 잃게 된다는 것을 의미합니다).

사람들이 다른 도서관이 자신의 필요를 더 잘 충족시킨다는 것을 알게 된다면 우리가 그들이 그것을 배우는 데 도움이 되어 기쁩니다. :)

그러나 스파이 및 스텁 메서드를 유지하거나 더 이상 사용하지 않고 기능을 일부 축소할 수 있습니까? 그것은 나에게 불분명했다.

그러나 스파이 및 스텁 메서드를 유지하거나 더 이상 사용하지 않고 기능을 일부 축소할 수 있습니까?

fake 가 안정적으로 보이면 spy 및 stub 를 더 이상 사용하지 않고 사람들이 업그레이드할 수 있도록 1년을 제공합니다.

사람들이 코드를 옮기는 데 도움이 되도록 codemod와 훌륭한 문서를 제공하기 위해 최선을 다해야 한다고 생각합니다.

저는 이 부분(기본 샌드박스)의 첫 번째 부분에 대한 분기 작업을 하고 있습니다. sandbox 와 collection 가 이제 하나가 되도록 코드를 리팩토링했습니다. 기본 샌드박스가 작동하도록 했습니다.

나는 앞으로 며칠 동안 커밋을 정리하고 업데이트된 API를 위해 이 리포지토리에 분기를 만들 것입니다.

이것은 좋은 아이디어입니다. 아주 잘 쓰여졌습니다.

나는 또한 스텁과 스파이에 사용 중단 통지를 추가할 것입니다.

또한 함수를 전달하여 키가 있는 객체 전달을 변경하는 방법에 대해서도 생각하고 있었습니다.

이렇게 하면 다음과 같은 이점이 추가됩니다.

• 이렇게 하면 typescript 또는 다른 종류의 정적 검사기를 사용하려는 사용자를 위해 해당 함수에 type 를 추가할 수 있습니다.
• 사용자가 존재하지 않는 동작에 대한 함수를 호출하려고 할 때 오류가 발생합니다.
• 우리는 이러한 기능을 별도로 문서화하고 문서를 훨씬 더 좋게 만들 수 있습니다.
• 이러한 동작에 의미가 없는 인수를 전달할 때 유용한 오류를 제공할 수 있으며 선택적/둘 이상의 인수를 가질 수 있습니다.
• (이 경우 많은 경우를 보지는 못했지만) 일을 더 구성 가능하게 만들고 사람들이 생성된 동작을 재사용할 수 있도록 합니다.
• IMO 이것은 또한 동작이 있는 객체를 갖는 것보다 간단합니다.

따라서 API는 대신 다음과 같이 표시됩니다.

// It would be cool to allow users to import these using destructuring to make code more concise
import { resolves, rejects, returns } from 'sinon/behaviors'; 

var fake = sinon.fake(resolves('apple pie'))

var fake = sinon.fake(rejects(new TypeError('no more pie')));
var fake = sinon.fake(rejects('no more pie'));

var fake = sinon.fake(returns('apple pie'));

var fake = sinon.fake(throws(new RangeError('no more pie'));
var fake = sinon.fake(throws('no more pie'));

이것을 구현할 때 당신이 제안하는 것과 같은 매우 단순한 객체를 반환하는 문제일 수 있습니다. 그런 다음, 하나 이상의 동작이 있는 경우 병합할 수 있습니다.

또한 onThirdCall 및 withArgs $와 같은 항목을 혼합하는 경우 이러한 경우에 어떤 일이 발생하는지 문서화해야 한다고 생각합니다.

너무 늦게 리뷰해서 죄송합니다. 지난 몇 개월은 매우 바빴습니다.

@lucasfcosta PR #1586을 확인하세요.

이 문제는 최근 활동이 없었기 때문에 자동으로 오래된 것으로 표시되었습니다. 더 이상 활동이 없으면 폐쇄됩니다. 귀하의 기여에 감사드립니다.

5.0.0 이전 버전은 package.json의 이후 5.0.0-next.* 시험판 버전에서 문제를 일으키고 있습니다. 5.0.0이 모든 시험판 버전보다 크기 때문입니다.

5.0.0이 나왔기 때문에 next 프리릴리즈 수치를 5.0.1-next.1 로 늘려야 한다고 생각합니다.

내가 사용하고 있던 다른 패키지가 더 이상 사용되지 않는 메시지를 받고 패키지의 package.json이 "sinon": "^5.0.0-next.4" 에 의존하기 때문에 이것을 알아차렸습니다.

npm WARN deprecated [email protected]: this version has been deprecated

이것이 시험판 문제에 대한 새 문제를 열 ​​가치가 있는지 확실하지 않았기 때문에 여기의 댓글이 가장 안전한 것 같았습니다.

또 다른 해결책은 다음 주 버전을 출시하는 것입니다. @sinonjs/core는 어떻게 생각하세요?

@mroderick v5의 모든 변경 사항이 무엇인지 더 이상 말할 수 없습니다. 나의 마지막 테스트에서 그것은 잘 작동했고 나는 새로운 가짜를 사용하기를 고대하고 있습니다. 새로운 전공이라 어서 보내주세요 😄

다음 주 버전을 출시하기 전에 병합하고 싶은 PR #1764가 하나 더 있습니다.

[email protected] 을(를) 게시했습니다. 그 동안 사람들의 삶이 더 쉬워지기를 바랍니다.

감사합니다. package.json에서 종속성을 테스트했으며(항상 다시 확인하는 것이 좋습니다) "sinon": "^5.0.1" 는 일치하는 항목이 없기 때문에 오류가 발생합니다(아직 릴리스 없음). "sinon": "^5.0.1-next.1" 해당 버전을 가져오는 데 제대로 작동합니다.

이것은 결코 큰 문제가 아니었습니다. 특히 v5가 한동안 개발 중이었기 때문에 그것이 출시될 때까지 얼마나 오래 걸렸는지 확신할 수 없었을 때 특히 당신에게 알려줄 가치가 있다고 생각했습니다. 가까운 시일 내에 출시하는 것이 좋은 아이디어라고 생각합니다.

fake 는 #1768과 함께 도입되어 [email protected] 가 되었습니다.