Mocha: ES6의 화살표 기능을 사용할 때 this.timeout()이 실패합니다

화살표 함수를 사용할 때 수행할 수 없는 테스트 컨텍스트에 함수를 바인딩합니다. http://mochajs.org/에서

미안합니다!

감사 해요.

왜 그렇게 많은 "마법"이 결국 문제를 일으키나요? 왜 안되나요?:

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', () => ... );  
});

전역도 없고 문제가 있는 마법도 없고... JavaScript만 있습니다.

당신이 제안하는 것은 주요 변경 사항이며 https://github.com/mochajs/mocha/issues/1969#issuecomment-160925915에서 논의되고 있는 것입니다. 재작성은 이러한 유형의 의미 체계를 도입할 수 있습니다. :)

반갑습니다. 감사 해요.

@ibc 글쎄, 그것은 있어야 할 것입니다

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', (suite) => ... );  
});

그러나 두 개의 다른 제품군 인수가 같은 유형입니까? 아마도 그렇지 않을 것이므로 다른 유형을 반영하기 위해 다른 변수 이름이 있습니다.

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', (test) => ... );  
});

어쨌든 화살표 연산자는 컨텍스트를 예상하는 함수에서 사용할 수 없습니다.

나는 설득할 수는 있지만, #1969의 BDD UI를 깨뜨릴 생각은 하지 않습니다. 기존 API를 유지하고 BDD UI가 포함된 별도의 패키지를 도입했으면 하는 바람입니다. Mocha는 기존 API를 사용하는 BDD UI 버전과 함께 제공되지만 이후 람다를 사용하여 BDD UI 패키지의 새 버전을 출시할 수 있습니다. 사용자는 해당 패키지로 명시적으로 업그레이드할지 여부를 선택할 수 있습니다.

describe 또는 suite 래퍼에 대한 대체 ES6 구문이 이 문제를 해결할 수 있습니다.

describe({ feature: 'create stuff' , do () {
    it('abc', () => {
    }); 
}})

이것은 적어도 스위트 레벨에서 바인딩을 허용합니다.

이에 대한 업데이트가 있습니까? 나는 이것을 가지고있다

mocha = require('mocha');

mocha.describe('test', (suite) => {

suite.timeout(500);

suite.it('test', (done)=>
          )
    }
)

그리고 TypeError 가져오기: 정의되지 않은 'timeout' 속성을 읽을 수 없습니다.

@mroien 이것은 Mocha 버그가 아닙니다. 화살표 구문은 function 대한 1:1 대체가 아닙니다. 제한 사항을 읽으십시오

이것으로 뭔가가 나왔습니까? 화살표 기능을 사랑하고 필요하지 않을 때 '이것'을 싫어한다면 제안된 솔루션이 마음에 듭니다.

timeout은 done 에만 관련이 있기 때문에 단순히 done 함수에 timeout 함수를 첨부하지 않는 것이 좋습니다.

it('makes sense', done => {
    done.timeout(100);
});

@nomilous 이것은 여전히 ​​작동하지 않습니다. 나는 비슷한 문제가 있었다. 내 경우에는 it 블록 내에서 setTimeout 호출합니다. 예

it('description', done => {
     const func = () => {
          // assertions
     };
     setTimeout(func, 10000);
});

@nomilous 동기 또는 약속을 반환하는 경우에도 시간 초과가 있을 수 있습니다.

@andela-engmkwalusimbi 이것은 작동하지 않아야 합니다. @bonekull 은 다음과 같이

@mroien 이것은 Mocha 버그가 아닙니다. 화살표 구문은 기능에 대한 1:1 대체가 아닙니다. 제한 사항을 읽으십시오

여전히 이것에 대해 궁금해하는 모든 사람들을 위해 화살표 기능이 의미하는 바를 이해했는지 확인한 다음 여기로 돌아와 계속 읽으십시오(저보다 훨씬 더 잘 설명할 수 있는 리소스가 많이 있습니다).

이 경우 이 화살표 함수가 작동하는 유일한 방법은 this 를 활용하는 대신 bdd API를 변경하여 context 개체를 모든 Runnable의 (후크, 테스트) 콜백에 전달하도록 하는 것입니다. this . 그것은 나쁜 생각은 아니지만 획기적인 변화의 지진이므로 절대 일어나지 않을 것입니다. 대신:

it('should do something', function (done) {
  this.timeout(9000);
  // stuff
  done();
});

그것은 다음과 같이 보일 것입니다 :

it('should do something', (context, done) => {
  context.timeout(9000);
  done();
});

그렇지 않으면 이전 버전과 호환되는지 여부에 관계없이 존재하는 모든 비동기 Mocha 테스트가 중단됩니다.

it('should do something', function (context, done) {
  // context is unused, but 'done' is now the second parameter
  this.timeout(9000);
  done();
});

우리는 이것을 하는 대안적인 bdd 구현을 제공할 수 있습니다. 그러나 이것은 단지 기본값이 아닙니다.

그것은 "이 문제가 어디에 있는지"에 대한 가장 철저한 설명입니다. :웃다:

차기 메이저 버전을 위해 고려해볼 수 있지 않을까요? 대체 bdd 구현을 만들기에 충분히 중요한 변경이라고 생각하지 않습니다. 명명된 인수가 있으면 향후 개발에도 도움이 될 수 있으며 다음과 같은 일종의 테스트 미들웨어를 추가하는 간단한 방법을 만들 수 있습니다.

it('should do something', function ({ context, done }) { ...

우리는 이것을 하는 대안적인 bdd 구현을 제공할 수 있습니다. 그러나 그것은 단지 기본값이 아닐 것입니다.

@boneskull 새로운 bdd-es6 인터페이스가 좋을 것입니다 :)

.filter(i => i.val) 와 같은 배열 함수에 정말 유용한 화살표 함수를 좋아하지만 일반 함수를 사용하는 데 어떤 문제가 있습니까? 설명하고 전역적으로 사용하는 것이 매우 유용하므로 매번 요구할 필요가 없습니다. 또한 this 가 언제부터 마술인지 (화살표) 기능을 이해하지 못하기 때문에? 약속을 반환할 수 있을 때마다 변수를 제공하고 싶지는 않습니다. 그렇지 않으면 오래전에 ava와 같은 것으로 전환했을 것입니다. 모카의 단순함과 관련하여 #1969에 설명된 일반/화살표 기능에 큰 변화가 없어야 한다고 생각합니다. 그리고 에디터가 f 를 function () {\n\t\n} 로 변환할 수 있기 때문에 화살표 함수가 입력하는 것이 더 빠르다고 말하지 마십시오.

확실하지 않습니다. 화살표 기능을 사용하는 before() 호출을 시간 초과하는 솔루션이 있습니까?

    before( async function () {
      data = await provider.getData();
      console.log(data);
      this.timeout(30*1000);
    });

효과가 없습니다. 여기에서 여전히 4초 시간 초과가 발생합니다. 이것은 내 테스트 스위트에서 유일하게 느린 것입니다. 문제를 해결하기 위해 mocha.opts 에서 시간 초과를 30초로 설정할 수 있지만 30초 후에 모든 테스트가 시간 초과될 필요는 없습니다.

그동안 해결한 방법은 다음과 같습니다(첫 번째 describe() 는 뚱뚱한 화살표 구문 대신 function 사용합니다.

describe('Search API', function () {
    this.timeout(30*1000);

    context('search', () => {
        let data;

        before( async () => {
          data = await provider.getSearch();
        });

        it('returns results', () => {
          expect(data).to.exist;
          expect(data.results).to.be.instanceOf(Array);
          expect(data.results.length).to.be.above(0);
        });
    })
});

@chovy await provider.getData() 에서 시간 초과가 발생한 후 시간 초과를 설정하고 있습니다.
대신 다음을 사용해 보세요.

before(async function () {
  this.timeout(30*1000); // set timeout first, then run the function
  data = await provider.getData();
  console.log(data);
});

확실하지 않습니다. 화살표 기능을 사용하는 before() 호출을 시간 초과하는 솔루션이 있습니까?

이 점을 분명히 하기 위해 현재로서는 화살표 함수를 사용하여 Mocha의 timeout 를 호출할 수 있는 방법이 없습니다. 대안에 대한 논의는(하지만 장점이 있더라도) 가능한 새로운(또는 최소한 수정된) 인터페이스에 대한 논의입니다.

내가 잠시 동안 마음속에 품고 있던 것은 할 수 있다는 것이었습니다.

it('...', (done) => {
  ...
  done()
})

그리고

it('...', (t) => {
  t.timeout(500)
  t.tag('integration', 'api')
  ...
  t.done()
})

동일한 기본 인터페이스를 사용합니다.

동일한 기본 인터페이스에서 둘 다 지원하면 기존 코드베이스에서 화살표 기능을 사용할 수 있습니다. 많은 온라인 튜토리얼에서 발견되는 (done) 구문은 플래그나 다른 것 없이도 여전히 작동할 것이라는 점을 지적할 가치가 있습니다.

따라서 이 구현에서는 기존 done 함수를 매개변수로 가져오지만 유틸리티 함수는 해당 done 함수 개체의 속성으로 추가됩니다.

this.timeout() 하면 보고서에서 경과 시간이 사라집니다.

@dasilvacontin 우리가 더 일찍 생각하지 못한 이유를 모르겠습니다. 그것은 훌륭한 아이디어입니다.

@dasilvacontin 아, 기억나네요. 불러야 하기 때문입니다. 원하지 않을 수도 있습니다.

죄송합니다. @bonekull "전화해야 함"에 대해 자세히 설명해 주시겠습니까? Mocha가 테스트가 비동기식이라고 생각하는 문제에 대해 이야기하고 있습니까?

2017년 1월 29일 05:54에 Christopher Hiller [email protected] 은 다음과 같이 썼습니다.

@dasilvacontin 아, 기억나네요. 불러야 하기 때문입니다. 원하지 않을 수도 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

또한 't'를 사용할 때 비동기 테스트를 수행하려는 의도를 어떻게 선언합니까?

테이프에서는 항상 '.done'(API의 '.end')을 호출하거나 예상되는 주장량('t.plan')을 설정해야 합니다.

옵션을 사용하여 it()에 세 번째 인수를 추가할 수 있습니까? 그것은 API를 깨뜨리지 않을 것입니다.

it ('accepts lambda', (done)=>{ doWork();  done(); }, {timeout:60000});

@boneskull

컨텍스트를 첫 번째로 두는 대신 두 번째 선택사항인 경우에는 어떻게 될까요?

대신:

it('should do something', function (done) {
  this.timeout(9000);
  // stuff
  done();
});

그것은 다음과 같이 보일 것입니다 :

it('should do something', (done, context) => {
  context.timeout(9000);
  done();
});

it('should do something', function (done, context) {
  // context is unused, but 'done' is now the second parameter
  this.timeout(9000);
  done();
});

우리는 이것을 하는 대안적인 bdd 구현을 제공할 수 있습니다. 그러나 그것은 단지 기본값이 아닐 것입니다.

그것은 "이 문제가 어디에 있는지"에 대한 가장 철저한 설명입니다. 😄

또는 컨텍스트가 정의된 매개변수여야 하는 경우

it('should do something', function (done, override) {
  // context is unused, but 'done' is now the second parameter
  override.timeout(9000);
  done();
});

그러나 기본이 아닌 인터페이스도 사용합니다. :)

done 가 필요한 솔루션의 단점은 약속을 반환하는 것이 더 간단하더라도 done 를 사용해야 한다는 것입니다. 직접 말해서 return 보다 .then(()=>{done()}, done) function 및 return 것이 좋습니다!

@Flamenco 흥미로운 아이디어이지만 기능을 마지막으로 사용하는 것을 선호할 수도 있습니다(예, 기술적으로 더 "마법적"인 방법이지만 직시합시다. 매개변수가 기능인지 확인하고 사용하기에 충분히 직관적입니다. 그리고 Mocha가 그러한 "마법"이 깨질 수 있는 일종의 다른 추상화로 공급되는 것과 같지 않습니다); 이러한 옵션 개체는 태그 및/또는 보류 중인 테스트 이유를 제공하는 데 사용할 수도 있습니다. 이 두 가지 모두 요청된 기능입니다(GitHub 문제/PR 목록 검색 상자에서 찾는 것은 독자에게 연습 문제로 남음). 동정심을 인정할 것입니다(그들의 부재를 해결하는 것이 가능하더라도 해결 방법보다 실제에 이점이 있음).

@ScottFreeCode done 에 대해 확실히 동의합니다. 저도 사용하고 싶지 않습니다. 컨텍스트를 맨 처음 대 마지막으로 배치해야 하고 앞서 언급한 뼈대에서 제공한 예제를 사용해야 하는 필요성에 대해 언급한 것입니다.

컨텍스트를 전달하거나 es6 실행을 위해 mocha의 일부 스위치를 설정하는 옵션이 마음에 듭니다.

그 동안 나는 derpy처럼 보이는 function() 호출에서 시간 초과 차이가 필요한 몇 가지 테스트 설명을 래핑하고 있습니다.

사용자 지정 시간 초과가 필요한 화살표 함수에서 약속이 mocha로 반환되는 사용 사례에 대한 해결 방법을 찾았습니다. 다른 사람들이 유용하다고 생각하는 경우 공유하고 싶습니다.

아래에 정의된 다음 when 함수를 다음과 같이 테스트 선언에 추가하면: it('does something', when(() => someFunctionReturningAPromise, customTimeout)) 화살표 함수를 포기하지 않고 mocha 시간 제한을 설정할 수 있습니다.

마찬가지로, 우리는 promise로만 작업하고 있기 때문에 테스트에 대한 첫 번째 매개변수를 다시 사용하고 완료된 콜백 대신 컨텍스트를 전달할 수 있습니다. it('can access the mocha test context', when(testContext => someFunctionThatNeedsContext(testContext))

const when = (lambda, timeout) =>
  function() { // return a plain function for mocha to bind this to
    this.timeout(timeout || this.timeout() || 1000)
    return lambda(this)
  }

설명할 몇 가지 테스트 사례:

const delay = timeout =>
  new Promise((resolve, reject) => setTimeout(resolve, timeout))

const deject = timeout => // similar to above, but a delayed reject
  new Promise((resolve, reject) => setTimeout(reject, timeout))

describe('mocha testing', () => {
  context('with only arrow functions', () => {
    context('tests that do not time out', () => {
      it('passes fast', when(() => delay(10), 100))
      it('does not usually time out', when(() => delay(2000), 2010))
    })
    context('tests that will time out', () => { // these should fail if the 'when' function works properly
      it('times out fast', when(() => delay(1000), 10)) // will fail in 10ms
      it('times out', when(() => delay(1000), 1000)) // will fail in about 1000ms
    })
    context('tests that will reject', () => { // this shows the when function works as expected when a test rejects
      it('fails fast', when(() => deject(10), 100))
    })
  })
})

@astitt-ripple 예, 아니면 단순히 function () {} ... Wtf?

알았어 루카, 물린데. :-)

화살표 함수와의 차이점은 반환을 건너뛸 수 있다는 것입니다. 에서
es6 유형 설정, 이것은 이미 promise 'then'의 일반적인 패턴일 수 있습니다.
쇠사슬.

기능 블록을 사용하여 제안한 대로, 그리고 내가 아는 한,
약속은 명시적이어야 합니다. 최소한의 약속 기반 테스트 기능
{... }가 잘못되었습니다. 테스트는 항상 약속을 반환해야 하므로 최소한의
유효한 사소화는 실제로 다음과 같습니다. function { return ... }. 그렇지 않으면
테스트는 디스패치된 약속이 아닌 mocha에 undefined를 반환합니다... 그리고
테스트 작성자는 나쁜 시간을 보내고 있습니다.

코드베이스의 대부분의 코드가 이미 promise.then의 화살표 함수인 경우
및/또는 함수형 프로그래밍 스타일, 함수 반환을 추가하면 다음을 볼 수 있습니다.
일관성없는. 제안된 '언제' 형식은 다음과 같은 사람들을 위해 대신 사용할 수 있습니다.
전통적인 기능보다 화살표와 더 기능적인 스타일을 선호합니다.
콜백 또는 함수 반환 스타일. 더 간결하고
컨텍스트 설명 dsl 우리 모두는 테스트를 작성하는 것을 좋아한다는 데 동의합니다.
약속 비동기 프로그래밍 추상화 자바 스크립트가 처리하는 계정
잘. 또한 우리 친구 곱슬이 없어도 function+return보다 짧습니다.
때(() => ...).

아마도 그것이 이 프로젝트에서 선호하는 스타일이 아닐 수도 있다는 점을 이해합니다.
나는 그것을 프로젝트의 변경으로 제안하지 않습니다. 어쩌면 그 짝수
당신의 wtf가 암시하는 것처럼 비난받을 수 있습니다. 괜찮아. 모카는 함께 일해야합니다
사전 fp 친화적인 js. 이전 버전과의 호환성은 최우선 관심사입니다. 저것
또한 의미가 있습니다.

이것은 길고 교착 상태에 있는 스레드이며 이것이 한 가지 방법입니다. 좋은 하나
자바 스크립트에 대한 것은 한 가지 또는 한 가지 스타일이 필요하지 않다는 것입니다.
일을 끝내라. 우리는 스타일에 대해 전혀 동의할 필요가 없습니다. 기능적으로
말하자면, 내 이전 게시물은 사람들에게 화살표와 약속을 사용하는 방법을 제공합니다
일관되게 그리고 모카에 대한 액세스를 포기하지 않고 테스트 dsl로
컨텍스트, 깨끗하고 기능적인 프로그래밍 친화적인 방식으로
이전에 제안되었습니다.

감사 해요.

코드베이스의 대부분의 코드가 이미 ... 함수형 프로그래밍 스타일인 경우 ...

...그런 다음 특히 이미 실행 중인 함수(또는 오히려 서브루틴)의 동작을 설정하기 위해 this.mutatingMethod(currentConfiguration) 를 사용하는 것은 return (단순한 구문임)를 작성하는 것보다 훨씬 일관성이 없습니다. , 그리고 일관되지 않은 모습은 실제로 불일치를 도입하기보다는 그 현실을 더 분명하게 만들 것입니다.

(오해하지 마세요. 저는 JS에서 함수형 프로그래밍 아이디어의 인기가 높아진 것에 매우 만족하지만 function / return vs => 의 구문은 함수형 프로그래밍에 실제로 필수적인 것은 아니지만 그 패러다임에서 더 깔끔하게 보이는 문제인 반면 순수성 및 선언적 대 명령형과 같은 다른 개념은 실제로 필수적입니다. 동작 / 의미론 , 이 시점에서 화살표 기능으로 전환하는 것은 아마도 사소할 것입니다...)

this.timeout이 돌연변이적이며 기능적 프로그래밍 패러다임에서 벗어난다는 데 동의합니다. 물론 완전히 일치하지 않습니다. 현재 this.timeout 외에 테스트별로 사용자 지정 시간 초과를 선언하는 다른 방법이 있습니까?

현재 mocha 구현에서는 명령형/돌연변이 패러다임으로 돌아가거나 테스트 시간 초과에 따라 설정을 포기해야 할 것 같습니다. 하나 또는 다른 하나.

위의 when 추상화에서 타임아웃은 when의 두 번째 매개변수로 기능 스타일이 테스트 수준에서 유지되도록 합니다. FP 모드에서 명령형 프로그래밍으로의 불가피한 탈출을 숨기지만 한 곳에서 수행합니다. 또한 화살표 함수에 mocha 컨텍스트에 대한 액세스 권한을 제공합니다. 이는 테스트 함수 매개변수 규칙을 위반하지 않고는 불가능합니다. 따라서 누군가가 테스트 실행자 아이디어를 탐색할 때까지 잠정적으로 이 프로젝트의 일부 사용자(이 문제의 기록으로 판단)에 대한 몇 가지 문제를 잠재적으로 해결할 수 있습니다.

또한 저를 오해하지 마십시오. 나는 함수형 프로그래밍이 튜링 머신에서 파생된 명령형/돌연변이 프로그래밍을 완전히 대체할 것이라고 생각하지 않습니다. 예를 들어 거의 모든 경우에 JS 런타임에서 기능 여부에 관계없이 코드는 궁극적으로 돌연변이를 중심으로 작성된 운영 체제에서 실행되는 보다 전통적인 명령형 스타일(아마도 C++이지만 반드시 그런 것은 아님)로 작성된 프로그램에 의해 해석됩니다. 그리고 명령형 아이디어(아마도 C). 메모리는 고정된 리소스이고 변경할 수 없는 데이터 구조는 런타임이 알려주는 거짓말입니다. 기본적으로 명령형 모델은 컴퓨팅의 기본이며 앞으로도 계속 유지될 것입니다. 그러나 이것이 함수형 프로그래밍이 그 위에 공존할 수 없다는 것을 의미하지는 않습니다. 그렇다면 FP 코드가 때때로 기본 모델로 드롭다운되어야 하는 것은 불가피합니다. 나는 그것이 우리가 손을 들고 모든 구문을 말하고 함수/리턴을 사용하자는 것을 의미해서는 안된다고 생각합니다.

실제로 => 함수 대신 function/return을 사용하여 함수형 프로그래밍을 수행할 수 있는 것과 마찬가지로 세부 사항에 대한 특정 허용 오차가 주어지면 C로 함수형 프로그래밍을 수행할 수 있습니다. 당신의 약속을 반환하는 것을 잊지 마십시오. C의 FP는 타이핑을 조금 더 필요로 하며 결국 구문일 뿐입니다.../s

하루가 끝나면 화살표 함수는 대중적인 언어로 람다 미적분학 모델에서 작업하는 실행 가능하고 실용적인 방법에 점점 더 가까워집니다. 이러한 추가 문자를 제거하면 작지만 중요한 차이가 생깁니다. 아직 실질적인 한계가 많이 있지만, 그 중 많은 부분을 해결할 수 있으며, 당면한 주제도 그 중 하나입니다.

어쨌든. 내가 제안한 도우미 기능을 사용하고 다른 사람들도 이제 무료로 사용할 수 있습니다. 나는 당신의 테스트 러너 솔루션을 기대하지만, 그 동안에는 구문이 중요한지 아닌지에 대한 우리 자신의 의견을 계속해서 서로 설득하는 것이 특히 생산적일지 모르겠습니다. 한 가지 방법입니다. 나는 화살표를 좋아하고 당신은 기능을 좋아합니다. 나는 내 견해를 바꾸는 설득력 있는 주장을 본 적이 없다. 나는 하나에 열려 있지만 "그냥 함수, wtf를 사용하십시오"또는 "더 자세한 _syntax_로 fp를 수행 할 수 있습니다"와 같은 무릎 꿇는 것보다 더 많이 생각하는 것이 좋습니다.

다른 방법으로 문제를 해결하면 아무도 when 를 사용할 필요가 없습니다. 그런가 말했다. :-)

나는 그것이 우리가 손을 들고 모든 구문을 말하고 함수/리턴을 사용하자는 것을 의미해서는 안된다고 생각합니다.

나는 화살표를 좋아하고 당신은 기능을 좋아합니다.

... "더 자세한 구문을 사용하여 fp를 수행할 수 있습니다"와 같은 엉뚱한 생각보다 더 신중해야 합니다.

그것은 내가 말한 것과 거의 정반대입니다. 여전히 this 사용하는 화살표 함수가 처음에는 FP가 아니라 화살표 함수( 전통적인 JS 함수를 사용하는 FP의 역함수). 다시 말해서, 단지 다른 구문이 아니라 실제 문제는 구문 비호환성보다 더 깊은 패러다임 비호환성이 있다는 것입니다(Mocha는 현재 어쨌든 설계되었으므로).

this 를 매개변수로 모두 대체하기 위해 Mocha 위에 대체 인터페이스를 구축하는 것이 가능하다고 확신합니다. 테스트 작성에서 FP가 되려면 Mocha의 this 를 화살표 함수에 전달하는 방법보다 더 많은 일을 해야 한다는 점을 분명히 하고 싶습니다. 그러나 나는 그런 종류의 도전에 대해 매우 고무적

(상태 저장(stateful), 글로벌(global), 또는 더 나쁜 - 둘 다인 Mocha의 몇 가지 다른 동작도 있지만 현재로서는 간단히 나열할 시간이 없습니다. Mocha를 두 번 이상 실행하는 것과 관련된 문제는 그 중 하나입니다.)

현재 this.timeout 외에 테스트별로 사용자 지정 시간 초과를 선언하는 다른 방법이 있습니까?

불행히도, 나는 그것이 없다고 확신합니다. 내 머리 꼭대기에서 구성 설정의 키-값 맵(JS 객체)이 될 it 대한 추가 매개변수를 수락하라는 제안은 누군가 원하는 경우 Mocha에서 괜찮은 미래 솔루션처럼 들립니다. 구현해보십시오.

현재 this.timeout 외에 테스트별로 사용자 지정 시간 초과를 선언하는 다른 방법이 있습니까?

불행히도, 나는 그것이 없다고 확신합니다.

이 세부 사항을 확인해주셔서 감사합니다. 이것은 내가 주장한 요점을 확고히 합니다.

누군가가 구현을 시도하려는 경우 구성 설정의 키-값 맵(JS 개체로)이 될 추가 매개변수를 수락하라는 제안은 Mocha의 괜찮은 미래 솔루션처럼 들립니다.

보다 일반적인 솔루션의 경우 +1입니다.

내가 말할 수 있는 바에 따르면 단일 매개변수를 계속 전달하는 것이 실행 가능한 것 같습니다. this 를 done 콜백과 결합합니다(따라서 this 는 함수가 됨). 그런 다음 mocha가 매개변수 수(오늘날 작동 방식에서 출발)에 관계없이 약속으로 래핑된 각 테스트를 실행합니다(실제로 두 개는 시간 초과를 처리하기 위한 것이고 다른 하나는 테스트를 실제로 실행하기 위한 것). 그런 다음 함수의 결과가 약속인지 여부를 확인할 수 있습니다. 그렇지 않은 경우 동기 함수가 반환된 후 done 호출하여 테스트를 완료합니다. 함수의 결과가 대신 약속이면 해결(또는 거부)될 때까지 기다립니다. 타임아웃이 발생하면 테스트를 중지합니다(이전과 동일). 테스트가 done 를 호출하고 프라미스를 반환하는 경우. 둘 중 하나가 확인 전에 호출되며, 이 경우 mocha는 약속을 기다린 다음 모호한 완료 시퀀스가 ​​있는지 테스트에 실패해야 합니다. 또는 done은 해결 후 언젠가 호출되며, 이 경우 어떻게든 테스트가 소급적으로 실패해야 합니다. 또는 문제가 다른 합리적인 방법으로 신호를 보냈습니다. 죄송합니다. 광범위한 획을 그렸지만, 모카가 무엇을 하려고 하고 어떤 문제가 발생하는지에 대한 제 외부인의 이해입니다. 이것이 실행 가능한 솔루션이 되는 것을 방해할 수 있는 다른 고려 사항은 무엇입니까?

테스트 작성에서 FP로 가고 싶다면 Mocha의 this를 화살표 함수에 전달하는 방법을 찾는 것 이상을 해야 합니다.

동의했다. 다른 계산 모델로 이동하는 데에는 확실한 변화가 있으며 자바스크립트는 고려해야 할 것이 많은 복잡한 생태계입니다. 그러나 내 특정 사용 사례에서 때때로 시간 초과를 설정하는 것(예: 고정 기본값 대신 일부 계산을 기반으로 더 정확함)은 Mocha로 FP 테스트를 작성하면서 만난 유일한 유형의 문제입니다(지금까지 적어도). 훌륭합니다. :+1:

즉, Mocha와 특별히 관련된 임박한 장애물이 무엇인지 알고 싶습니다(FP에서 테스트 작성이 일반적으로 의미하는 것과 반대됨).

내가 말한 것과는 거의 반대이지만

제가 표현을 잘못했거나 잘못 이해했다면 죄송합니다. 내가 쓴 많은 부분에 대해 답장을 기반으로 의도한 대로 전달되고 있는지 확신할 수 없습니다. 불행한 일입니다. 만약 우리가 그것에 도달했다면 FP가 _이론에서 _어떻게_ 보여야 하는지에 대해 꽤 가까운 합의에 도달할 것이라고 생각하기 때문입니다. 그러나 여기서는 적어도 일부 사용자/사용 사례에 대해 현재 사용 가능한 Mocha 릴리스에서 _practice_에 대한 실행 가능한 축소가 어떻게 보일지에 대해 동의하지 않는 것 같습니다. 그래서 내가 제안한 추가 기능의 주요 문제가 귀하의 입장에서 정확히 무엇인지 잘 모르겠습니다.

(순서대로 인용하고 대답했지만, 틀림없이 더 중요한 것은 더 이른 것보다 더 늦은 것입니다.)

내가 말할 수 있는 바에 따르면 단일 매개변수를 계속 전달하는 것이 실행 가능한 것 같습니다. 이것을 done 콜백과 결합합니다(그래서 이것은 함수가 됩니다). 그렇다면... 이것이 실행 가능한 솔루션이 되지 못하게 할 수 있는 다른 고려 사항은 무엇입니까?

이전 버전과의 호환성을 깨면 더 간단한 디자인으로 전환할 수 있습니다.

이전 버전과의 호환성을 유지한다면 이 두 테스트는 모두 통과해야 하고 타임아웃이 되지 않아야 합니다.

it("runs immediately", () => {
  // call functions and assert whatever
})
it("runs asynchronously", doneWithSomeOtherName => {
  setTimeout(() => {
    // call functions and assert whatever
    doneWithSomeOtherName()
  }, 100)
})

그렇지 않으면 증명하기 위해 몇 가지 예제 코드를 제시하는 것을 환영합니다(비록 이 주석 끝에 있는 제안에 중점을 두는 것이 좋습니다). 그러나 어떤 디자인도 그렇게 할 수 없을 것이라고 확신합니다. 또한 이 테스트를 통과하고 시간이 초과되지 않도록 합니다.

it("looks just like an asynchronous test with a different name for `done`, but never tells Mocha it's done", context => {
  context.configureByMutation("some value")
  // call functions and assert whatever
})

그러나 또한 거기에 돌연변이가 있음을 주목하십시오. 이에 대한 자세한 내용은 아래에서 확인하세요.

그러나 내 특정 사용 사례에서 때때로 시간 초과를 설정하는 것(예: 고정 기본값 대신 일부 계산을 기반으로 더 정확함)은 Mocha로 FP 테스트를 작성하면서 만난 유일한 유형의 문제입니다(지금까지 적어도). 훌륭합니다.

:+1:!

즉, Mocha와 특별히 관련된 임박한 장애물이 무엇인지 알고 싶습니다(FP에서 테스트 작성이 일반적으로 의미하는 것과 반대됨).

내가 이 초점을 정확히 전달하지 못했을 수도 있다고 생각합니다. 그래서 조금 더 요약할 수 있는지 보겠습니다. (이 중 하나라도 적대적인 것으로 여겨진다면 유감입니다. 물론 의도한 것은 아니지만 여기서 마음가짐을 바꾸려고 노력한다는 점을 인정하겠습니다.) Mocha의 코드베이스는 클래스 계층 구조와 getter 및 setter 스타일의 대부분입니다. "객체 지향"(그리고 Mocha에는 여러 가지 문제 또는 잠재적인 문제가 있다고 생각합니다)가 있지만, 테스트를 작성하고 Mocha가 테스트를 실행하도록 하는 것이 전부인 경우 일반적으로 테스트 코드에 영향을 미치지 않습니다. . Mocha의 명령형 변경 구성으로 이상한 일을 할 수

it("imperatively sets the timeout multiple times", function(done) {
  this.timeout(5000)
  var context = this
  setTimeout(function() {
    context.timeout(1000)
    setTimeout(done, 500)
  }, 4000)
})

...하지만 그럴 필요는 없습니다. 기능적이지 않은 언어에서 기능적으로 프로그래밍하는 많은 요소와 마찬가지로 명령적인 내용을 남용하지 마십시오.

(예외가 불순하다는 주장도 있지만 입력을 기반으로 throw되는 예외가 사실인지 아직 확신하지 못합니다. 이는 다른 형태의 출력으로 간주될 수 있습니다. 따라서 일부는 주장을 사용하여 다음과 같이 말할 것입니다. 그 throw는 작동하지 않지만 이 시점에서 다루지 않을 것입니다.)

(여기서 중요한 부분:) 제가 얻으려고 하는 것은 이미 복잡한 코드베이스에 복잡성을 추가하거나 이전 버전과 호환되지 않는 변경을 잠재적으로 고려하고 있다는 것입니다. 우리는 그 중 하나에 대한 정당화가 필요합니다. 정당화가 "테스트를 더 기능적으로 만들기"라면 그것은 좋은 것입니다 (어쨌든 내 책에서). 테스트를 더 기능적으로 만드는 디자인은 문제의 가치가 있을 수 있습니다(문제의 정도에 따라 다름). 그러나 "테스트를 더 기능적으로 만듭니다"라는 말이 "화살표 기능을 변경하게 하다", 즉 "화살표 기능을 덜 기능적으로 만듭니다"를 의미하는 경우 사례를 많이 약화시킵니다(그냥 자기모순적이지 않은 경우). 더 완전하게: 테스트 를 더 기능적으로 돌연변이를 제거하는 것이 좋습니다.

나는 아마 이 접선에 대해 너무 멀리 가지 말았어야 했다. 솔루션에 대해서는 아래를 참조하십시오. 😸

그래서 내가 제안한 추가 기능의 주요 문제가 귀하의 입장에서 정확히 무엇인지 잘 모르겠습니다.

(여기에서도 중요한 부분입니다:) 사실 저는 timeout 를 메소드 호출 대신 매개변수로 사용하는 비트를 좋아합니다! Mocha의 나머지 구성 방법으로 일반화할 수 있는 방법을 생각해 낼 수 있다면(많은 방법이 있습니다. 일부는 제 기억이 맞다면 동기 테스트에 적용되므로 동일한 방법을 추가할 수 없는 이유는 무엇입니까?) 의 속성 done 및하자 사람들은 통해 구성 호출 할 수 있습니다 비동기 테스트 쓰기 done 나는 확실히 그것을보고 싶을 것,하지만 난의 탈선을). 적어도 우리는 그것을 추천하게 할 수 있으며, 우리는 심지어로 구현 채택 할 수있을 it 어쩌면, 그런 세 번째 매개 변수 (또는 뭔가를 통과 할 때 it.configured 또는 it(...).configured(...) 우리가 더 많은 수-의 파라미터 헛소리 ...)하지 않으려면 - 나는 태클 기본 돌연변이 / 필수 물질과는 "기능 지원 화살표 권리를 얻을 수있는 이전 버전과 호환 솔루션이 될 것이라고 생각 방법"(내가 주장하는 것은 어쨌든 그러한 것입니다): 새로운 행동에 적합하기 때문입니다. 해결 방법에서 this 를 사용하는 대신 다음과 같이 말했어야 했습니다. 매개변수 부분을 확장해 보겠습니다!

나는 당신이 다음과 같이 할 수 있는 곳에서 읽었습니다.

describe('a slow thing', () => {
 // test code...
}).timeout(5000);

제공된 함수에 대한 매개변수 계약을 변경하지 않습니다. 지금은 그런 것에 대한 참조를 찾을 수 없으므로 그냥 상상했을 수도 있습니다.

@thom-nic 작동합니다! 모카의 모든 함수가 컨텍스트를 반환하기 때문에 의미가 있다고 생각합니다.

return this;

화살표 기능 형식을 일반 기능으로 바꿀 때 나와 함께 작동합니다.

기능() { ..... }

안녕 여러분. 8월에 다시 토론을 촉발한 후 어두워진 것에 대해 사과드립니다. 저는 꽤 바빴고 실제로 그 작업에서 대부분 완료/이동했습니다.

다양한 사용 사례와 함께 연결하기가 얼마나 어려운지에 대한 자세한 답변에 감사드립니다. 그것은 내가 읽은 것 중 mocha가 지원해야 하는 다양한 설정을 가장 간결하게 보여주는 것이었습니다. 시간 내주셔서 감사합니다.

돌이켜보면 모카 컨텍스트( this )에 대한 액세스 권한을 얻는 것을 지나치게 강조했음이 분명합니다. 그 측면은 나중에 생각하기에 더 편리합니다. 내가 실제로 하려고 했던 일에서 얼마나 쉽게 주의를 끌지 몰랐습니다. 일회성 간소화를 위해 테스트 dsl에 일시적인 확장( when )을 추가하여 재미를 봤습니다. 시간 초과 조정(아래에서 설명할 특정 스타일의 테스트에 대한 일반적인 오류 제거). this 반환하는 것은 내가 추가하려고 생각한 또 다른 재미있는 일이었습니다. 주요 아이디어(따라서 when 라는 이름)는 평소와 다른 시간 초과가 필요한 경우를 처리하는 것이었습니다.

분명히 바인딩된 컨텍스트에 액세스하려면 래퍼로 끌어올리는 대신 function 를 많은 사람들이 제안한 대로 직접 사용할 수 있습니다. 그게 문제가 아닙니다. 😄 그것이 겉으로 보기에는 이상하게 보일 수 있다는 사실을 잊지 않습니다. 나는 처음에 나를 이 길로 인도한 몇 가지 테스트를 설정하는 방법을 보여주면 그림이 완성될 수 있기를 바랍니다. 분명히 말씀드리자면, 저는 여기서 특정한 스타일을 판매하려는 것이 아니라 귀하에게 적합한 것을 사용하십시오. 이것이 나를 위해 일한 것입니다.

확인
먼저, 기본적으로 한 가지 작업을 수행하지만 광범위한 입력에 대해 수행할 일부 설정을 테스트하고 있다는 가정으로 시작합니다. 따라서 출력이 올바른지 확인하기 위해 여러 시나리오에서 이 작업을 테스트해야 합니다. . 그러나 관련 응용 프로그램 코드가 "한 가지 작업을 수행"하기 때문에 기본 테스트 절차는 거의 항상 동일합니다. 또한 테스트 본문을 불필요하게 복제/변경하고 싶지 않습니다. 새 입력에 대해 더 많은 테스트 케이스를 추가할 수 있는 속도가 느려지고 결국 유지 관리가 비합리적으로 되기 때문입니다.

그래서 대신 우리는 잠재적으로 지원되는 입력으로 애플리케이션 코드를 시작하고 테스트 작업을 수행한 다음 결과를 주장하기에 충분히 일반적인 함수를 작성합니다. 제 경우에는 Promise 추상화로 작업하고 있었습니다. 생략하겠습니다), 그래서 이 일반화된 테스트 절차 함수는 자연스럽게 그 promise.then 체인을 반환해야 합니다. 빵과 버터 es6 종류의 물건, 지금까지 너무 좋습니다.

이제 테스트 시나리오가 나옵니다. 모든 것을 테스트 절차 함수에 담았기 때문에 테스트 케이스는 효과적으로 입력을 정의하고 함수를 호출하고 있습니다.

그래서 아마도 다음과 같은 테스트를 많이 작성하고 모든 것이 _seems_ 작동하는 것 같습니다.

it('does something', function() {
  testProcedureFunction('something','1')
})

잘 따라오셨다면 이 예제에 버그가 있다는 것을 이미 눈치채셨을 것입니다. return 이 누락되어 있고 testProcedureFunction은 약속(말장난 의도)을 기반으로 하기 때문에 끝에 있는 주장이 통과하든 실패하든 상관없이 항상 통과할 것입니다. 이것은 버그이며 때때로 추적하기에는 매우 미묘한 것일 수 있습니다. 설명하기 위해 testProcedureFunction을 작성하는 방법과 응용 프로그램을 작성하는 방법에 따라 시작 시 동기 코드가 있고 테스트 종료 주장 대신 폭발하는 경우 테스트 케이스가 실패할 수도 있습니다. 모든 것이 괜찮다고 생각하는 것.

물론 테스트는 다음과 같이 반환되어야 합니다.

it('does something', function() {
  return testProcedureFunction('something','1')
})

이제 이 테스트가 대부분의 경우 한 줄이라는 것을 압니다. 실제로 입력이 더 큰 시간 초과가 필요한 경우를 제외하고 모든 경우는 한 줄입니다. 이제 고전적인 js 함수와 화살표의 차이점 중 여기에서 유용한 화살표 함수의 특정 측면이 있습니다. 단일 명령문 화살표 함수는 중괄호가 생략될 때 암시적인 반환을 가집니다. function {...} 를 작성하는 대신 테스트에서 => ... 를 사용하면 화살표와 중괄호가 없는 경우를 쉽게 스캔하고 이 누락된 return 가질 수 없다고 빠르게 추론할 수 있습니다.

이렇게:

it('does something', () => testProcedureFunction('something','1'))

이제 이러한 경우 중 하나가 다른 경우보다 더 오래 걸린다면 어떻게 될까요! 물론 다음과 같이 시간 초과를 설정할 수 있습니다.

it('does something slow', function() {
  this.timeout(10000)
  return testProcedureFunction('somethingSlow','2')
})

아니면 누군가가 실수를 해서 먼저 이것을 할 것입니다(물론 작동하지 않습니다):

it('does something slow', () => {
  this.timeout(10000)
  return testProcedureFunction('somethingSlow','2')
})

그러나 이제 우리는 우리가 시작했던 곳으로 돌아왔습니다. 코드베이스는 반복하기에 무르익은 패턴을 가지고 있으며 누락된 반환 버그에 취약합니다(미래의 나 또는 다음 사람이 기능을 추가할 수 있습니다. 요점은 실수하면 눈에 띄지 않을 수 있으며 추적하기 어려울 수 있습니다.) when 함수는 이 문제를 해결하고 화살표를 다시 일관되게 사용할 수 있도록 합니다.

it('does something slow', when(() => testProcedureFunction('somethingSlow','2'), 10000))

(참고로 위의 .timeout(5000) 도트 체인 제안을 작동하지 못했습니다. 사용해야 했던 모카 버전 때문일 수 있습니다. 더 이상 기억이 나지 않습니다. 노력하다!)
(참고 2, when 사용은 this 매개변수 호이스팅 트릭을 사용하지 않는다는 점에 유의하십시오. 이는 실제로는 나중에 생각한 것입니다).

누락된 약속에 대한 수익 버그를 표시할 수 있는 린터가 있을 수 있습니다(또는 더 현실적으로는 모든 함수에 대해 rhs로 return 문을 적용). 그러나 그 당시 옵션이 아니었다 플러스 (주관적 / 개인적으로) 쉽게 읽을 멀리에서 나를 위해 비늘을 밀고와 작업, 나는 화살표 구문은 짧은 나오는 생각하고 나는 그것을 찾을 수 function .

그래서 당신은 그것을 가지고 있습니다.

조만간 다시 답장을 보낼 시간이 있을지 모르겠지만 최소한 정보가 있고 명확했으면 하며 "화살표에서 모카 컨텍스트에 대한 액세스" 항목을 둘러싼 논쟁을 침대.

마지막으로, 나는 function vs => 가 오랫동안 혼란스럽다는 것을 알았기 때문에, 왜 화살표가 this 접근할 수 없는지 아무 생각 없이 읽는 사람에게 명확하지 않은 경우를 대비하여 이 링크를 삭제하겠습니다. 내가 찾은 기능 대 화살표에 대한 가장 명확한 설명이었고 마침내 완전히 자신감을 가지고 사용할 수 있을 만큼 차이점을 이해하는 데 도움이 되었습니다.

https://hacks.mozilla.org/2015/06/es6-in-depth-arrow-functions/

@thom-nic it 에서는 작동하지만 describe 에서는 작동하지 않습니다.

describe('my test suite', () => {

  it('test case 1', () => {
    // ...
  }).timeout('10s');  // Works on `it`. This test case doesn't timeout

  it('test case 2', () => {
    // ...
  });  // This test case timeouts.

}).timeout('10s');  // Doesn't work on `describe`. Tests are already created when runs to here.

@thom-nic, 일반 함수 형식을 사용할 수 있습니다.

describe('my test suite', function() {
this.timeout(n);

...
}

이것에 대해 불평하는 사람은 화살표 기능을 이해하지 못합니다.

화살표 함수는 새로운 멋진 ES6이 아니라 고전적인 function () {} 를 대체해야 합니다. 화살표 함수의 유일한 목적은 부모로부터 this 를 상속한다는 것입니다. 여기서 고전적인 function () 에는 자체 this 있습니다.

예, 전체 ES6 구문을 사용하는 경우에도 함수의 올바른 컨텍스트에서 this 를 사용하려면 여전히 function () 를 사용해야 합니다. 수행하려는 작업에 따라 ES6 애플리케이션에서 function () 및 () => 를 모두 사용해야 합니다.

this.timeout() 는 it('....', () => { ... }) 와 함께 작동하지 않습니다. 콜백이 this 상위 describe() 함수에서 this 를 상속하기 때문입니다. 여기서 this.timeout() 는 그 수준에서 의미가 있습니다.

람다 함수를 사용하면 호출에서 선언하지 않고 함수에 단일 인수를 자동으로 보낼 수도 있습니까?

(param)=>a함수
...그때(aFunction)

function(){}은 'this'에 바인딩될 수 있지만 ()=>는 '고정'되어 있습니다.

화살표 함수는 수신자가 호출된 것과 동일한 컨텍스트에서 미리 결정된 'this'를 예상 할 때 기존 함수를 대체 해야 하며(또한 적은 코드 입력의 이점도 있음)

'이것'을 호출할 때 '이것'이 아닌 다른 것을 원하지 않는 한 결코 function()을 사용하지 않는다고 말할 수 있습니다.

@플라멩코...

람다 함수를 사용하면 호출에서 선언하지 않고 함수에 단일 인수를 자동으로 보낼 수도 있습니까?

나는 당신이 그것을 넣는 방법을 _정확히_ 이해하고 있는지 잘 모르겠습니다.
"함수에 인수 보내기"에 관한 한, 굵은 화살표는 한 가지 예외를 제외하고 일반 함수처럼 작동합니다. 정확히 1개의 인수가 있는 경우 괄호를 생략할 수 있습니다.

() => console.log("hi"); //zero arguments requires empty parenthesis
a => console.log(a); //you can optionally leave the parenthesis off for 1 argument
(a,b) => console.log(`${a} ${b}`); //2..n arguments requires parenthesis

함수가 단일 표현식인 한 굵은 화살표를 사용하면 중괄호와 return 키워드를 생략하여 값을 _반환_할 수 있습니다.
그래서 당신이 있었다면 ...

setTimeout(function(a,b) { doSomething(); return calculateSomething(a,b); }, 5000);

...그리고 그것을 뚱뚱한 화살표 함수로 변환하고 싶었습니다. 함수 본문에 여러 문이 있기 때문에 중괄호와 return 키워드를 흔들 수 없습니다. 이런식으로 하시면 됩니다...

setTimeout((a,b) => { doSomething(); return calculateSomething(a,b); }, 5000);

차라리 시작했다면...

setTimeout(function(a,b) { return calculateSomething(a,b); }, 5000);

...너무 간단해서 단일 표현식을 반환하고 사용할 수 있는 함수를 다루고 있습니다...

setTimeout((a,b) => calculateSomething(a,b), 5000);

읽기가 훨씬 쉬워졌습니다!
codefoster.com/levelup-arrays 에서

JavaScript에는 OOP에서 FP까지, 엄격한 유형 안전성에서 mixin/duck-typing에 이르기까지 다양한 코딩 스타일이 있습니다. 또한 각 스타일에는 고급 패턴이 있습니다(예: OOP 캠프의 종속성 주입, FP 캠프의 커링/모나드).

어디 코딩 스타일은 가까운 FP하는 경우 this 사용하고 기능을 화살표되지 않고 보존하는 데, 상용구를 줄이기 위해 사용되는 this (예 : 생성, 테스트 파라미터 어떤 고급 테스트에 대한 추가 오버 헤드 DSL).

숙련된 개발자라면 누구나 자신의 코딩 스타일에 맞게 테스트 프레임워크를 미리 래핑할 수 있지만 이는 프레임워크가 "즉시 사용 가능한" 수준이 아님을 의미합니다. 즉, 업그레이드, 플러그인 채택, 새 엔지니어 온보딩을 위한 추가 작업이 필요합니다.

this 를 사용하지 않고 대신 describe , it 매개변수로 컨텍스트 개체를 전달하는 대체 bdd 인터페이스 아이디어가 마음에 듭니다 this it 및 후크.

그러나 IIRC를 구현하는 것은 그리 간단하지 않습니다. 그래도 시도를 보면 멋질 것입니다.

나는 이것이 심각한 부작용에 빠지고 있다는 것을 알고 있지만, 이와 같이 done-or-context 매개변수를 처리할 수 없습니까?

it("runs immediately", () => {
  // call functions and assert whatever
})

it("runs asynchronously", doneOrContext => {
  setTimeout(() => {
    // call functions and assert whatever
    doneOrContext();
  }, 100)
})



md5-b1fe6f00c87a2916712cf6a4df16e142



it("runs immediately using the parameter as a context", doneOrContext => {
  doneOrContext.configureByMutation("some value");
  // As well as changing config, also flags to Mocha that this test is treating the
  // parameter as a context object and is therefore not async.
  // Call functions and assert whatever
})



md5-b1fe6f00c87a2916712cf6a4df16e142



it("runs asynchronously using the parameter as a context", doneOrContext => {
  doneOrContext.configureByMutation("some value");
  doneOrContext.setAsync(); // Flags to Mocha that even though the parameter has been used as
  // a context object, the test is in fact asynchronous.
  setTimeout(() => {
    // call functions and assert whatever
    doneOrContext();
    // or doneOrContext.done()
  }, 100)
})

아래 스크립트를 사용했지만 동일한 시간 초과 초과 오류가 발생했습니다.

마이스크립트:

describe("getBillingDetail", 비동기 함수(){
this.timeout(55000);
it.only("지정된 유효한 작업 이름 확인", 비동기 함수(완료){
this.timeout(55000);
var 결과 = 대기 url.getBillingDetail('12254785565647858');
console.log(결과);
assert.equal(결과, 참);
});
});

오류: 55000ms의 시간 초과가 초과되었습니다. 비동기 테스트 및 후크의 경우 "done()"이 호출되었는지 확인하십시오. Promise를 반환하는 경우 해결되는지 확인하십시오.

비동기 함수에 완료된 콜백을 전달하지 마십시오.

이전 버전과 호환되는 프로토타입 솔루션을 만들었습니다. 지금은 별도의 모듈이지만 기능을 적절한 mocha 쉽게 병합할 수 있습니다.

https://github.com/papercuptech/mocha-lambda

빠른 길

require('mocha-lambda')
// now a global '_tst' can be used where 'this' was before

describe('suite', () => {
  beforeEach(() => {
    _tst.answer = 42
  })

  it('provides "this" as "_tst"', function() {
    assert(this === _tst)
  })

  it('works', () => {
    assert(_tst.answer === 42)
    _tst.skip()
  })
})

명시적 이름 지정(TypeScript와 함께 작동)

// if you were previously explicitly importing api (describe, it, etc.) from 'mocha',
// you will have to change to importing from 'mocha-lambda', until (or if) this
// gets merged into mocha proper
import ctx, {describe as d, it as i} from 'mocha-lambda'

d('suite', () => {
  // ctx() is a function that returns "this" as appropriate
  i('works using ctx()', () => {
    ctx().skip()
  })
})

import {Context} from 'mocha'
// ctx() can also rename global
ctx('t')
declare var t: Context
d('suite', () => {
  // ctx() is a function that returns "this" as appropriate
  i('works using renamed global', () => {
    t.skip()
  })
})

@papercuptech 링크 404를 찾을 수 없습니다.

웁스.. 개인 저장소였습니다. 이제 공개

npm i mocha-lambda도 가능

@alung @linesh-simplicity, 이것은 #3485로 대체되었습니다.

감사 해요.

왜 그렇게 많은 "마법"이 결국 문제를 일으키나요? 왜 안되나요?:

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', () => ... );  
});

전역도 없고 문제가 있는 마법도 없고... JavaScript만 있습니다.

@thom-nic 답변을 참조하고 청소하고 트릭을 수행했습니다.

나는 당신이 다음과 같이 할 수 있는 곳에서 읽었습니다.

describe('a slow thing', () => {
 // test code...
}).timeout(5000);

제공된 함수에 대한 매개변수 계약을 변경하지 않습니다. 지금은 그런 것에 대한 참조를 찾을 수 없으므로 그냥 상상했을 수도 있습니다.

@thom-nic 솔루션이 저에게 효과적이었습니다. 감사합니다!