Jest: 기대에 대한 사람이 읽을 수 있는 컨텍스트

야! 그래서 우리는 실제로 Jasmine에 이것을 가지고 있었지만 FB에서 수천 개의 테스트 파일이 있지만 아무도 그것을 사용하지 않는다는 것을 발견했습니다. 그래서 지금 우리는 대략적인 정보와 예상으로 이어지는 스택 추적이 포함된 멋진 오류 메시지를 인쇄하고 있습니다(스크린샷에서와 같이). 나는 우리가 던지는 줄을 인쇄할 수 있다는 데 동의하지만 종종 주장이 여러 줄로 길어집니다.

expect(a).toEqual({
  …
});

그래서 이것은 실제로 그렇게 좋아 보이지 않을 것이고 파서를 사용하여 JS를 구문 분석하고 관련 정보를 추출하거나(긴 줄을 축소) 보기 좋게 만들기 위해 이와 유사한 것을 사용해야 합니다.

개인적으로 현재로서는 충분한 정보를 보여주고 있다고 생각하지만 재고하게 되어 기쁩니다. 그다지 복잡하지 않지만 문제를 더 빨리 해결하는 데 도움이 되는 컨텍스트를 추가하는 것에 대한 아이디어가 있으면 알려주십시오.

우리는 실제로 Jasmine에 이것을 가지고 있었지만 FB에서 수천 개의 테스트 파일이 있지만 아무도 그것을 사용하지 않는다는 것을 발견했습니다.

@cpojer 그래서 패턴은 it 에서 각 주장을 래핑하는 것입니까? 및/또는 행 번호를 신뢰합니까?

이 패턴이 더 좋거나 나쁘기 때문에 덜 채택되었지만 기존 테스트와의 일관성을 위해 더 많이 채택되었을 수 있습니까? 또는 기능의 존재를 모르십니까? 이것이 자스민에 있는지 몰랐습니다.

나는 우리가 던지는 줄을 인쇄할 수 있다는 데 동의하지만 종종 주장이 여러 줄로 길어집니다.

한 줄로 리팩토링하면 어설션에 더 많은 의미 정보를 제공할 수 있습니까? 아마도?

const adminUser = {
  …
}
expect(a).toEqual(adminUser);

개인적으로 현재로서는 충분한 정보를 보여주고 있다고 생각하지만 재고하게 되어 기쁩니다.

위의 예는 모든 것에 장황한(IMO) 래퍼를 추가하지 않는 한 어떤 어설션이 실패했는지 정확히 발견하기 어렵다는 것을 보여줍니다. 이것은 소스맵 행 번호가 항상 정확하지 않은 트랜스파일 환경에서 특히 그렇습니다. 간결한 테스트처럼 빠르고 정확하게 이해가 깨지고 어디가 중요한지 생각합니다.

그다지 복잡하지 않지만 문제를 더 빨리 해결하는 데 도움이 되는 컨텍스트를 추가하는 것에 대한 아이디어가 있으면 알려주십시오.

위에서 몇 가지 제안을 했습니다.

• 어설션 메서드에 대한 추가 선택적 매개변수
• 연결된 컨텍스트 메시지

더 간단하거나 다른 것을 찾고 있습니까?

안녕하세요 @timoxley입니다! 우리는 이미 이와 같은 것을 추가하는 것에 대해 생각했습니다.

따라서 첫 번째 옵션의 문제는 일부 매처에 선택적 인수가 있어 상황이 더 복잡해진다는 것입니다.

예를 들어 여기 두 번째 경우에는 인수가 근접성인지 오류 메시지인지 알 수 없습니다.

expect(555).toBeCloseTo(111, 2, 'reason why');
expect(555).toBeCloseTo(111, 'reason why');

무언가가 기대를 충족하지 못하는 즉시 match가 던지기 때문에 두 번째 제안은 작동하지 않습니다.

expect(1).toBe(2)/* will throw here */.because('reason');

다음과 같이 매처가 실행되기 전에 이유를 첨부할 수 있습니다.

expect(1).because('reason').toBe(2);
// or 
because('reason').expect(1).toBe(2);

하지만 이 API는 그다지 좋아 보이지 않습니다.

또 다른 옵션은 expect 에 두 번째 인수를 추가하는 것입니다.

expect(1, 'just because').toBe(2);

그러나 이전 옵션과 거의 동일합니다.

이것이 별로 유용하지 않다고 생각하는 이유는 엔지니어가 테스트 작성에 시간을 낭비하고 싶지 않기 때문입니다. 그들을 더 어렵게 만들기 위해 우리가 하는 모든 일은 더 나쁜 테스트로 이어질 것입니다.

과거에는 실제로 사용자 지정 매처를 만드는 것이 가장 좋은 솔루션이었습니다. Jest의 다음 버전에서 expect.extend 를 소개할 예정이며 이를 통해 다음과 같은 매처를 쉽게 만들 수 있습니다.

expect(a).toEqualMySpecificThing(…)

이를 통해 보다 표현적인 실패 메시지를 작성할 수 있습니다. 나는 이것이 Relay와 같은 프로젝트에서 많이 사용되는 것을 보았습니다. 모든 매처 보기: https://github.com/facebook/relay/blob/master/src/tools/__mocks__/RelayTestUtils.js#L281

활동이 없어 문을 닫지만 좋은 아이디어가 있으면 다시 열 수 있습니다.

@cpojer @dmitriiabramov 지연에 대해 사과드립니다.

expect 에 대한 두 번째 인수 또는 .because 로 이유를 연결하는 것이 좋습니다. 이것을 가능하게 하거나 하지 않기 위해 무엇을 해야 합니까?

엔지니어는 테스트 작성에 시간을 낭비하고 싶지 않습니다.

@cpojer 동의합니다! 테스트 디버깅에 시간을 낭비하고 싶지 않은 것 외에도 이것이 더 많은 실패 컨텍스트가 있는 덜 장황한 API가 더 바람직하다고 생각하는 바로 그 이유입니다.

일부 구체적인 숫자의 경우 위의 내 설명에 있는 간단한 예를 사용하여 테이프를 사용하여 동등한 주장 + 컨텍스트를 얻으려면 Jest는 프로그래머가 의식용 상용구 양의 거의 두 배를 작성해야 합니다.

• 1.8배 라인(6 대 11)
• 2배 들여쓰기(1 대 2)
• 2x 괄호/곱슬(24 대 48) !

이것은 개선될 수 있습니다!

// tape
test('api works', t => {
  t.deepEquals(api(), [], 'api without magic provides no items')
  t.deepEquals(api(0), [], 'api with zero magic also provides no items')
  t.deepEquals(api(true), [1,2,3], 'api with magic enabled provides all items')
  t.end()
})

// jest
describe('api works', () => {
  test('api without magic provides no items', () => {
    expect(api()).toEqual([])
  })
  test('api with zero magic also provides no items', () => {
    expect(api(0)).toEqual([])
  })
  test('api with magic enabled provides all items', () => {
    expect(api(true)).toEqual([1,2,3])
  })
})

업데이트 : 화살표가 있는 한 줄에 농담 테스트를 작성할 수 있다고 가정합니다.

// jest
describe('api works', () => {
  test('api without magic provides no items', () => expect(api()).toEqual([]))
  test('api with zero magic also provides no items', () => expect(api(0)).toEqual([]))
  test('api with magic enabled provides all items', () => expect(api(true)).toEqual([1,2,3]))
})

이렇게 하면 줄이 더 길어지지만 이전에 비교한 통계가 다소 향상됩니다.

• 0.8x 라인(6 대 5)
• 1x 들여쓰기(1 대 1)
• 1.75x 괄호/곱슬(24 대 42)

그러나 줄 바꿈 없이 줄 시작 부분에 테스트 설명이 있으면 테스트의 "핵심", 즉 실제 어설션을 임의의 열 위치에 배치하기 때문에 논리를 시각적으로 구문 분석하기가 더 어려워집니다.

코드를 파싱하는 것은 테스트 설명을 읽는 것보다 더 중요합니다. 이는 기본적으로 찬사를 받는 설명일 뿐입니다. 이것이 행의 시작 부분에 아무도 주석을 쓰지 않는 이유입니다. 예를 들어 이것은 사도마조히즘적 광기일 것입니다:

/* api without magic provides no items */ expect(api()).toEqual([])
/* api with zero magic also provides no items */ expect(api(0)).toEqual([])
/* api with magic enabled provides all items */ expect(api(true)).toEqual([1,2,3])

이상적으로는 모든 어설션 코드가 동일한 열에 깔끔하게 정렬되어 사람이 쉽게 구문 분석할 수 있습니다. 이 생각을 바탕으로 expect 에 대한 두 번째 인수의 대안 제안보다는 후행 .because 형식을 강력하게 선택합니다.

대화를 계속해주셔서 감사합니다. 또한 설명 블록이 필요하지 않으므로 더 작게 만듭니다. .because 는 불행히도 작동하지 않습니다. 왜냐하면 matcher가 던질 때( .because 가 호출되기 전에 발생함), 이름을 추출할 방법이 없기 때문입니다.

그러면 각 매처 함수의 마지막 인수를 사용하시겠습니까?

expect 의 두 번째 인수로 추가하는 경우에만 작동합니다.
모호성 때문에 모든 매처 함수의 마지막 인수로 추가할 수 없습니다.
예

expect(obj).toHaveProperty('a.b.c', 'is that a reason or a value of the property?');

활동이 없어 문을 닫지만 좋은 아이디어가 있으면 다시 열 수 있습니다.

@cpojer expect(value).toBe(something, 'because message') 의 재스민(및 기타) 방식이 배제되었는지 여부가 불분명합니까?

한 가지 예는 상태 머신을 테스트하는 redux-saga/redux-observable 항목을 테스트하는 것입니다. 어떤 상태에서 실패했는지에 대한 설명 메시지가 있으면 매우 유용합니다. 저 예시는 인위적인거라 설명도 그렇고..

@jayphelps 모든 재스민 매처를 다시 작성했기 때문에 더 이상 재스민 방식을 사용하지 않습니다.

@dmitriiabramov 죄송합니다. 제 질문이 명확하지 않았습니다. 재스민 _way_ 그것을 다시 추가하도록 판결을 받았습니까? 그들이 허용하는 것과 같은 일을 합니다.

@jayphelps 전에 말했듯이 모호성 때문에 모든 매처에서 작동하지 않습니다.

expect(obj).toHaveProperty('a.b.c', 'is that a reason or a value of the property?');

노래 jest matchers는 타사 패키지로 확장할 수 있습니다. 인수 목록을 엉망으로 만드는 것은 좋은 생각이 아닙니다.

가장 깔끔한 옵션은 expect 의 두 번째 인수로 사용하는 것입니다. 항상 정확히 하나의 인수를 취하기 때문입니다.

expect(123, 'jest because').toEqual(123);

그래도 API를 오버로드하고 싶은지 잘 모르겠습니다. 우리는 페이스북 테스트 스위트에서 거의 사용하지 않았으며 특별한 경우에는 새 테스트를 정의하는 것이 더 쉽다고 생각합니다.

beforeEach(someSharedSetup);
test('reason or description', () => expect(1).toBe(1));

몇 줄만 더하면 됩니다 :)

또는 다른 describe() 호출에 넣을 수도 있습니다.

@dmitriiabramov 성가신 경우는 사가, 서사시 등의 상태 머신에서와 같이 상태를 구축할 때입니다. 각 테스트에는 이전 상태 변경이 필요하며, 이를 분리하려면 AFAIK 이득 없이 엄청난 양의 복제가 필요합니다.

it('stuff', () => {
  const generator = incrementAsync();

  expect(generator.next().value).toBe(
    call(delay, 1000)
  );

  expect(generator.next().value).toBe(
    put({ type: 'INCREMENT' })
  );

  expect(generator.next()).toBe(
    { done: true, value: undefined }
  );
});

또는 다른 describe() 호출에 넣을 수도 있습니다.

이것을 자세히 설명해 주시겠습니까? 중첩 설명 호출 AFAIK는 섹션 제목을 나누기 위한 것이었고 테스트는 여전히 동시에 실행됩니까?

테스트 스위트(파일)는 동시에 실행되지만 test() 호출은 실행되지 않습니다.

나는 다음과 같은 것을 생각하기 시작했습니다.

test('111' () => {
  jest.debug('write something only if it fails');
  expect(1).toBe(2);
});

일이 될 수 있습니다

이 토론 과 이 저장소 에서 멋지고 의미 있는 저장소는 다음과 같을 것이라고 생각합니다.

it('has all the methods', () => {
  since('cookie is a method').expect(reply.cookie).toBeDefined();
  since('download is a method').expect(reply.download).toBeDefined();
  since('end is a method').expect(reply.end).toBeDefined();
  // ...
});

사용법은 because 와 비슷하지만 의미상 더 의미가 있습니다.

당신이 이것을 좋아한다면 나는 since 기능을 추가하는 PR을 할 수 있을 것입니다.

이 작업을 수행하는 쉬운 방법을 구현하십시오. 나는 그것을 자주 사용하지 않지만 특히 더 복잡한 테스트의 경우 파고들지 않고도 무엇이 실패하는지 정확히 아는 것이 도움이 됩니다.

"테스트 스위트를 더 간단하게 다시 작성하십시오"라고 말하지 마십시오. 엔지니어가 _writing_ 테스트 스위트보다 더 싫어하는 유일한 것은 _rewriting_ 테스트 스위트입니다.

내가 어디선가 본 또 다른 제안은 이것이 작동하지 않는 이유에 대한 설명과 함께 이 동일한 문제의 위치를 ​​잊어버렸습니다 . 좀 자야겠네요 :)

간단한 "프로토타입" 데모가 작동 중입니다. 이제 재귀를 구현해야 합니다. 전역 변수 주위에 프록시를 사용한 다음 각 메서드에 대해 사용하는 얇은 래퍼입니다. 그러나 프록시는 이전 브라우저에서 지원 되지 않으며 폴리필할 수 없으므로 Jest에서 허용되지 않을 수 있습니다. 다음은 래퍼의 일반 구조입니다.

const since = (text) => {
  return new Proxy(global, {
    get: (orig, key) => {
      return (...args) => {
        try {
          const stack = orig[key](...args);
          return new Proxy(stack, {
            get: (orig, key) => {
              return (...args) => {
                try {
                  const ret = orig[key](...args);

                  // ... implement recursion here

                } catch (err) {
                  console.log('2', key, text, err);
                  throw err;
                }
              }
            }
          });
        } catch (err) {
          console.log('1', key, text, err);
          throw err;
        }
      };
    }
  });
};

세 가지 현실적인 옵션이 있습니다.

• 이 방법은 허용되므로 기본 Jest 라이브러리에 추가해야 합니다. 정리하고 PR을 작성합니다.
• Jest에 대해 더 깊이 파고들어 핵심 라이브러리를 수정합니다. 많은 작업, 그래서 일부 회원(들)이 이 문제/방향에 대해 반공식적으로 말할 때까지 아무 것도 하지 않을 것입니다.
• 이 방법으로 완료하고 패키지로 게시하십시오. 쉽게 발견할 수 없기 때문에 바람직하지 않습니다.

편집: 실제 사용:

describe('Test', () => {
  it('works', () => {
    since('It fails!').expect('a').toEqual('b');
  });
});

사소하지 않은 테스트가 있을 때 테스트 결과를 정상으로 만들려면 기대 컨텍스트가 필요합니다. 실제 테스트가 항상 그렇게 간단한 것은 아닙니다.

사용자 지정 매처를 기억하십시오 - 수학 복잡성을 숨깁니다. 그러나 테스트가 실패하면 실패에 대한 최대 정보를 원하기 때문에 이러한 복잡성을 숨기는 것은 원하는 것이 아닙니다. 기대 컨텍스트를 사용하면 이 컨텍스트를 수동으로 제공할 수 있습니다. 내 생각에 이상적이지는 않지만 일종의 자동 컨텍스트가 더 나을 것이지만 지금까지 본 유일한 방법입니다.

내가 무언가를 부수고 실패하면 Jest를 사용하여 수동으로 디버깅하거나 로깅 또는 _modifications._를 추가해야 합니다. 이는 테스트 실행 결과를 보는 것보다 훨씬 덜 편리합니다.
예를 들어 Jasmine에는 실패에 대해 더 이해하기 위해 일부 컨텍스트를 인쇄할 수 있는 기능이 있습니다.
Java의 가장 인기 있는 테스트 프레임워크인 JUnit에도 똑같은 기능이 있습니다.

내가 틀렸다면 미안하지만 여기에 이 ​​기능에 대한 _기술적_ 반론이 없습니다. 그리고 "보기에 좋지 않기 때문에 추가하면 안 된다"와 같은 것은 그저 우스꽝스럽습니다.

다시 열 수 있습니까? 위의 @aaronabramov 가 제안한 jest.debug() 조차도 저에게 도움이 될 것입니다.

This:

it('has all the methods', () => {
    since('cookie is a method', () => expect(reply.cookie).toBeDefined());
});

can be supported by adding this:


// setupTestFrameworkScriptFile.js
// http://facebook.github.io/jest/docs/configuration.html#setuptestframeworkscriptfile-string
global.since = (explanation, fn) => {
    try {
        fn();
    } catch(e) {
        e.message = explanation + '\n' + e.message;
        throw e;
    }
};

또한 jasmine-custom-message 는 요청한 것과 유사하게 보입니다.

describe('test', function() {
  it('should be ok', function() {
    since(function() {
      return {'tiger': 'kitty'};
    }).
    expect(3).toEqual(4); // => '{"tiger":"kitty"}'
  });
});

다시 열 계획이 있습니까? 최근에 이 문제가 중복된 것 같습니다. 또한 테스트가 실패할 때 사용자 지정 메시지를 표시하려고 합니다.

흠.. 이것도 위시리스트에 있는 것. 이 스레드를 읽은 후 Facebook에서 Jest 사용과 관련된 응답을 이해할 수 있고 자신의 워크플로에 영향을 미치고 싶지 않지만 기존 테스트를 방해하지 않는 몇 가지 제안이 있었고 여러 다른 사람들이 원하는 기능을 추가할 것입니다. (저 포함) 있습니다.

두 번째 인수가 expect() 또는 since() 형식이 PR로 허용되려면 어떻게 해야 합니까? 나는 이것을 돕기 위해 기꺼이 시간을 할애합니다.

방금 스레드를 읽고 양쪽에서 좋은 주장을 보았습니다. @timoxley가 원래 게시한 것과 같은 이유로 사용자 지정 오류 메시지를 제공하는 메커니즘을 확실히 원합니다. 지금은 다음과 같이 하고 있습니다.

import assert from 'assert'
import chalk from 'chalk'

test('api works', () => {
  assert.deepEqual(
    api(),
    [],
    chalk.red('api without magic provides no items')
  )
  assert.deepEqual(
    api(0),
    [],
    chalk.red('api with zero magic also provides no items')
  )
  assert.deepEqual(
    api(true),
    [1, 2, 3],
    chalk.red('api with magic enabled provides all items')
  )
})

이것은 실제로 매우 잘 작동하지만 분필을 사용하여 빨간색을 얻는 것을 피하고 싶습니다 expect

나는 그것이 어떻게 정직하게 구현되었는지에 대해 별로 신경 쓰지 않는다. 그러나 다른 사람들이 선호하는 경우를 대비하여 since 에 대한 대안이 있습니다.

const expectWithMessage = expect.withMessage(
  'api with magic enabled provides all items'
)
expectWithMessage(api(true)).toEqual([1, 2, 3])

// could be rewritten like
expect
  .withMessage('api with magic enabled provides all items')(api(true))
  .toEqual([1, 2, 3])

since 보다 더 좋아하는지 확신할 수 없습니다. 뭐든지 다 잘어울려요 정말 갖고싶네요 :)

아, 그리고 댓글에 답하자면:

이것이 별로 유용하지 않다고 생각하는 이유는 엔지니어가 테스트 작성에 시간을 낭비하고 싶지 않기 때문입니다. 그들을 더 어렵게 만들기 위해 우리가 하는 모든 일은 더 나쁜 테스트로 이어질 것입니다.

테스트 작성을 더 어렵게 만들고 싶지 않다는 데 동의합니다. 이것이 추가 변경이 되는 이유입니다. 따라서 테스트를 디버그하기 쉽게 만드는 "시간 낭비"를 원하지 않는 사람들은 유용한 메시지를 건너뛸 수 있습니다. 시간을 내어 주장을 조금 설명해주신 엔지니어 :wink:

안녕하세요 @cpojer 이에 대한 업데이트가 있습니까?

Jest는 이 문제를 제외하고는 훌륭하게 작동하고 있습니다... 현재 저는 for 루프 내에서 실패한 어설션을 수정하기 위해 고군분투하고 있습니다.
expectationsArray.forEach(expectation => expect(...))

사용자 정의 오류 메시지 없이 어떤 기대가 실패하는지 정확히 파악하기 어렵습니다(내가 잘못하지 않는 한..?)

감사합니다

@mj-airwallex 예를 들어 for 루프에서 test 로 기대치를 감쌀 수 있습니다.

const expectationsArray = [[0, 'a'], [1, 'b']];

expectationsArray.forEach(([expectation, desc]) => {
  test(`test ${desc}`, () => {
    expect(expectation).toBeGreaterThanOrEqual(2);
  });
});

또한 기대하는 동안 사용자 지정 메시지를 제공해야 하기 때문에 농담에 문제가 있습니다. test 아래에 기대치를 래핑하는 것은 비동기식 호출이 필요하지 않은 경우에 작동하는 것 같습니다. 그러나 Jest는 프라미스를 반환하는 describe (#2235 )를 처리할 수 없으므로 test 로 래핑하는 것과 함께 비동기 호출로 테스트를 생성할 수 없습니다. 그리고 여러 test 중첩할 수 없습니다.

다음은 문제를 설명하는 예입니다.

async function getArray() {
  return [0,0,0,0,0,0]
}

describe('Custom messages with async', async () => {
  const array = await getArray();
  array.forEach((item) => {
    test(`test${item}`, () => {
      expect(item).toBe(0)
    });
  });
})

이것을 처리하는 방법에 대한 아이디어가 있습니까?

OP의 문제를 살펴보면("어떤 기대가 실패했는지 즉시 명확하게 해주는 사람이 읽을 수 있는 컨텍스트가 있으면 좋을 것입니다"), 이제 해결되었다고 생각합니다. Jest 22부터 우리는 실패한 주장의 컨텍스트를 인쇄합니다. 추가 메시지가 여전히 필요합니까? _is_인 경우 어설션 위 또는 옆에 있는 코드 주석일 수 있습니다.

비동기 설명은 또 다른 문제입니다(추가된 코드 프레임으로는 도움이 되지 않음).

비동기 설명을 사용하지 않고 대신 beforeEach 또는 beforeAll 를 사용한다고 생각합니다.

@kentcdodds beforeEach 또는 beforeAll 로 이것을 처리하는 방법의 예를 제공할 수 있습니까? beforeEach 및 beforeAll 에 필요한 모든 비동기 호출 결과를 빌드하려고 하면 결국 허용되지 않는 중첩된 test 를 생성해야 합니다.

아, 당신이 그 비동기 통화로 무엇을 하고 있었는지 보고 싶었습니다. 죄송합니다 😂 네, beforeEach 또는 beforeAll 을(를) 수행할 수 없습니다.

@SimenB , 컨텍스트를 인쇄하면 이미 많은 도움이 되며 사용자 지정 메시지와 관련된 대부분의 문제를 해결합니다. 감사합니다! 그러나 루프 내에서 예상을 사용하는 것과 같은 상황에서 도움이 되기 때문에 사용자 지정 메시지를 인수로 명시적으로 사용할 수 있는 가능성이 있으면 좋을 것입니다.

@tojuhaka 이것을 시도하십시오 : https://github.com/negativetwelve/jest-plugins/tree/master/packages/jest-plugin-context

OP의 문제를 살펴보면("어떤 기대가 실패했는지 즉시 명확하게 해주는 사람이 읽을 수 있는 컨텍스트가 있으면 좋을 것입니다"), 이제 해결되었다고 생각합니다.

예, 대부분의 Jest 사용자가 갖게 되는 변환 전에 원본 소스에 액세스할 수 있는 한 원본 문제를 해결합니다. IMO는 사용자가 실패와 함께 사용자가 제공한 메시지를 인쇄할 수 있도록 허용하는 것에 비해 약간 무겁지만 충분히 좋은 것 같습니다.

Jest를 사용하기 시작했는데 이와 같은 기능이 없습니다. 내 사용 사례:
객체의 속성이 진실이라고 주장하는 테스트는 실패합니다. 어설션이 실패할 경우 개체를 기록할 수 있다면 실패를 더 빨리 이해하는 데 도움이 될 것입니다.

이를 위해 toHaveProperty 를 사용할 수 있습니다.

test('property', () => {
  expect({foo: 'bar'}).toHaveProperty('baz', 'foobar');
});

거기에 있는지 확인하려면 두 번째 인수를 삭제하십시오. _some_ 값이 있다고 주장하려는 경우 expect.anything() 사용할 수 있습니다.
toMatchObject 는 또 다른 대안입니다.

원하는 경우 assert 를 사용할 수도 있습니다.

test('property', () => {
  const obj = {foo: 'bar'};
  assert.equal(obj.baz, 'foobar', JSON.stringify(obj));
});

팁 고마워. assert.equal(obj.baz, 'foobar', JSON.stringify(obj)); 는 내 특별한 경우에 작업을 수행합니다.

@SimenB @mpseidel 주장이란 무엇입니까? 타사 라이브러리입니까? jest 문서에서 아무것도 찾을 수 없습니다.

@sharikovvladislav assert 는 노드 코어 모듈입니다 https://nodejs.org/api/assert.html

@mpseidel 앗 ! 나는 몰랐다. 감사합니다. 효과가있다.

다음 코드 조각을 사용하여 프레임워크의 이러한 제한을 해결하고 있습니다(TypeScript에서 JS에 대한 유형 주석을 제거하면 됩니다).
export const explain = (expectation: () => void, explanation: string) => { try { expectation(); } catch(e) { console.log(explanation) throw e; } }

안녕,
아무도 루프에 대해 언급하지 않았다는 사실에 놀랐습니다. 메시지는 단순한 문자열이 아니라 루프 반복에 따른 동적 문자열입니다.
jest-plugin-context 는 훌륭합니다. 덕분에 작동하지만 약간 무겁고 초기 문제는 여전히 관련이 있습니다.
이 테스트를 봐

describe('MyStuff', () => {
    it('should render and contain relevant inputs', () => {
      const wrapper = shallowWrapped(<MyStuff />);
      const expectedKeys = ['love','jest','but','need','details','for','expect'];
      expectedKeys.forEach((key) => {
        expect(wrapper.find({ id: key }).length).toEqual(1);
      });
    });
  });

당신의 범인을 찾는 행운을 빕니다. 지금 당장 {len:.., key:..} 와 같은 개체를 대신 추가하거나 테스트해야 합니다. 이것은 깨끗하지 않고 사용자 친화적이지 않습니다.
이 사용 사례는 예를 들어 양식 및 항목 렌더링 확인과 관련이 있다고 생각합니다.
구문은 toEqual(1).context("my message") 또는 toEqual(1, "my message") 만큼 간단할 수 있습니다(물론 구현이 항상 더 어렵다는 것을 알고 있으며 Jest에서 수행한 훌륭한 작업을 존경합니다).

chai 와 같은 형식을 사용할 수도 있습니다. 즉, 메시지를 예상 호출에 두 번째 인수로 추가합니다.

expect(foo, 'this detail').toEqual(2)

티

이전에 재스민을 사용했기 때문에 지원되지 않는 것을 찾아 여기에 왔습니다.
그러나 afik 이러한 것들은 모두 함수입니다. 다음과 같이 하면 안 될까요?

describe('MyStuff', () => {
    describe('should render and contain relevant inputs', () => {
      const wrapper = shallowWrapped(<MyStuff />);
      const expectedKeys = ['love','jest','but','need','details','for','expect'];

      expectedKeys.forEach((key) => {
        it(`contains key "${key}"`, () =>
          expect(wrapper.find({ id: key }).length).toEqual(1)
        )
      })
  });
});

@akkerman 좋은 솔루션입니다. describe 및 it은 jest에서 제공하는 마법의 전역이므로 모호하게 느껴질 수 있다는 점을 인정해야 하므로 루프에서 't'를 쓰는 것이 작동할 수 있는지 확신할 수 없었습니다.

다른 수정자를 연결하는 것은 어떻습니까?

expect(foo).toEqual(bar).because('reason with %s placeholders')

또는 아마도 기능

expect(foo).toEqual(bar).explainedBy((result) => `Lorem ipsum ${result}`)

다른 수식어는 빨리 읽을 수 없게 되는 것 같아요.
티

2018-04-19 13:47 GMT+02:00 λ • Geovani de Souza [email protected] :

다른 수정자를 연결하는 것은 어떻습니까?

expect(foo).toEqual(bar).because('%s 자리 표시자가 있는 이유')

또는 아마도 기능

기대(foo).toEqual(bar).explainedBy((결과) => Lorem ipsum ${result} )

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/facebook/jest/issues/1965#issuecomment-382705387 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAM5PwBCvET1KdEDeDEF7gGo708Naj8oks5tqHlSgaJpZM4Kc6Uu
.

--

타르제이 후세
모빌: 920 63 413

expect 작동 방식은 던지는 것이므로 어쨌든 작동하지 않습니다.

expect(something, 'some helpful text on failure').toEqual(somethingElse) 또는 expect.context(something, 'some helpful text on).toEqual(somethingElse) 가 가장 좋은 대안이라고 생각하지만 둘 중 어느 것도 마음에 들지 않습니다.

이거 재개봉 가능한가요? Jest는 여전히 여러 상호 작용에서 상태가 어떻게 변경되는지 테스트하기 위한 좋은 솔루션이 없는 것 같습니다. 예를 들면 다음과 같습니다.

• 일련의 이벤트에 대한 응답으로 상태 저장 React 컨테이너가 어떻게 변경되는지 테스트
• Puppeteer를 사용하여 여러 상호 작용에서 웹 페이지가 어떻게 변경되는지 테스트

이 두 경우 모두 일련의 작업을 수행하고 각 작업 후에 상태가 어떻게 변경되었는지(또는 변경되지 않았는지) 주장해야 하므로 다중 주장 테스트가 때때로 필요합니다. beforeEach 로 이런 종류의 문제를 해결하는 것이 항상 가능한 것은 아닙니다.

저는 이것이 정말 유용할 상황을 계속 찾습니다. 특히 @callumlock이 설명하는 것처럼 여러 상호 작용 및 어설션을 실행할 때.

사람들이 싫어하지 않는 API를 생각해 낸다면 이것이 당신이 추구할 의향이 있습니까? 정말 유용하고 많이 사용되는 기능이라고 생각합니다.

제안된 솔루션을 요약하면 다음과 같습니다.

expect(api()).toEqual([]) // api without magic provides no items
it('api without magic provides no items', () => expect(api()).toEqual([]))
test('api without magic provides no items', () => expect(api()).toEqual([]))
expect(api()).toHaveNoItems()

expect(api(), 'api without magic provides no items').toEqual([])
expect(api()).because('api without magic provides no items').toEqual([])
since('api without magic provides no items').expect(api()).toEqual([]))
because('api without magic provides no items').expect(api()).toEqual([]))
jest.debug('api without magic provides no items'); expect(api()).toEqual([]))

.because() 후행은 불가능하므로 옵션으로 포함되지 않습니다.

첫 번째 그룹의 네 가지 옵션이 모두 오늘 지원됩니다. 개인적으로 첫 번째 옵션(주석이 있는 코드 프레임)이 훌륭하게 작동한다는 것을 알았습니다. 커스텀 매처(옵션 4)를 사용하는 것보다 훨씬 좋습니다.

이에 대한 움직임을 만들기 위해 우리가 이해해야 할 것은 다음과 같습니다. 첫 번째 그룹의 옵션보다 두 번째 그룹의 옵션에 대해 더 매력적인 점은 무엇입니까? 두 번째 그룹은 우리가 제공하는 모든 매처(비동기 매처, 비대칭 매처, 스파이 매처, throw 매처, 약속 매처 및 사용자 지정 매처)에 대한 핵심 유지 관리를 정당화할 수 있는 무엇을 추가합니까?

안녕,
기본적으로 몇 가지 사용 사례가 있습니다.

• 다중 주장 테스트(테스트에서 여러 항목을 주장해야 함)
• 동적으로 생성된 어설션 컨텍스트(예: 많은 테스트를 받았기 때문에 실패한 개체의 특정 필드를 인쇄하기 위해 오류 메시지의 변수를 더 명확하게 만들기를 원함)
• 동적으로 생성된 어설션(어설션을 생성하는 루프를 만듭니다)

첫 번째 그룹 옵션은 주로 첫 번째 사용 사례를 위한 것입니다. 제안된 대로 동적으로 생성된 어설션이 필요한 경우 테스트가 루프에서 새 테스트를 생성할 수 있도록 it 및 test 에 대한 호출을 중첩할 수 있습니다. 문제는 주장 이 아니라 테스트 를 생성한다는 것입니다. 1000개 요소 배열의 각 요소에 대해 무언가를 주장하고 싶다고 상상해 보십시오. 이렇게 하면 테스트 요약이 부풀려집니다.

이러한 동적 사용 사례는 여전히 드물기 때문에 유지 관리자에게 최소한의 작업이 필요한 솔루션을 고수해야 합니다. 저는 개인적으로 because/since 솔루션을 좋아합니다. 매우 간단하게 들리기 때문입니다. 구현은 대부분 expect 를 try/catch 에 래핑하여 메시지를 인쇄하고 반환하는 것 같습니다.
jest.debug 이상하게 들립니다. 테스트가 실제로 통과하더라도 디버깅이 메시지를 인쇄하는 것입니다.
"마지막 인수" 옵션도 좋지만 expect 가 다양한 인수를 허용할 수 있으므로 실행 가능한지 확실하지 않습니다.

나는 어떤 옵션도 괜찮습니다. 나는 단지 그 기능을 원한다. 저는 jest.debug API에 대해 별로 관심이 없지만 이 기능을 원하기 때문에 의미가 있는 유일한 API라면 괜찮습니다.

@kentcdodds 기존 옵션 4개는 어떻습니까?

@eric-burel test.each 및 describe.each 가 Jest 23에 추가된 것을 보았습니까(Jest <23의 경우 독립 실행형으로 사용 가능)?

내가 말했듯이, 나는 우리가 어떤 옵션을 선택하는지 별로 신경 쓰지 않습니다. 기능이 있기를 바랄 뿐입니다. 우선 순위를 지정하면 다음과 같을 것입니다.

1. expect(api(), 'api without magic provides no items').toEqual([])
2. because('api without magic provides no items').expect(api()).toEqual([]))
3. since('api without magic provides no items').expect(api()).toEqual([]))
4. expect(api()).because('api without magic provides no items').toEqual([])
5. jest.debug('api without magic provides no items'); expect(api()).toEqual([]))

(test|describe).each 는 훌륭하지만 단일 테스트에서 여러 작업/어설션을 사용하려는 문제를 해결하지 못합니다.

이 기능은 현재 4가지 옵션이 있습니다.

expect(api()).toEqual([]) // api without magic provides no items
it('api without magic provides no items', () => expect(api()).toEqual([]))
test('api without magic provides no items', () => expect(api()).toEqual([]))
expect(api()).toHaveNoItems()

이것들이 뭐가 잘못됐나요? 제안된 _new_ 솔루션은 이러한 기존 솔루션보다 약간 더 나은 것 같습니다. 유지 관리 비용을 정당화할 수 있는 이점은 무엇입니까?

@rickhanlonii 니스 test.each 에 대해 몰랐습니다. 정말 좋은 기능입니다. 지적해 주셔서 감사합니다. 배열에서 동적으로 생성된 테스트인 내 세 번째 사용 사례의 문제를 해결한다고 생각합니다.

그래서 그것은 내가 나열한 두 번째 항목을 남겼습니다: 동적으로 생성하는 실패 메시지가 있어서 디버깅이 더 빨라졌습니다. 지금은 사용 사례가 많지 않습니다. 아마도 개체 필드 값을 테스트할 때 실패 시 전체 개체를 인쇄하고 싶을 것입니다. 미미하거나 약간 중복되더라도 테스트 작성을 더 쉽게 만드는 것은 합법적인 imo입니다. 결국 우리는 it 및 test 둘 다 쓸 수 있습니다. 차이점이 없는 한 이것은 대부분 편안함을 위한 것입니다.
미미하지만 이 스레드에서 볼 수 있듯이 사용자가 실제로 기대하는 것(말장난 없음)입니다.

편집: it 또는 test 를 사용하여 다른 테스트에서 테스트를 생성하고 테스트에 대해 동적으로 생성된 이름은 유효한 솔루션이지만 어설션 생성을 의미할 때 테스트 생성을 정말 좋아하지 않습니다. . 이 스레드에서 솔루션이 제공되지 않았다면 가능하다고 생각하지 않았을 것입니다.

이건 미쳤어. expect()에 두 번째 선택적 매개변수를 추가하기만 하면 됩니다. 그것을 사용하고 싶은 사람은 (선택적으로), 사용하지 않는 사람은 사용하지 않을 것입니다.

Mocha는 이것을 영원히 해왔습니다... 그것은 제가 몇 년 전에 Jasmine을 포기한 이유 중 하나입니다. 다른 재스민 파생물.

오류 시 메시지를 출력하는 것은 다른 많은 테스트 프레임워크의 관례이며 Jest에서는 이를 볼 수 없다는 사실에 놀랐습니다. 이 스레드에서 많은 유용한 예제를 찾았지만(감사합니다) 테스트 실패 시 사용자 지정 오류를 인쇄하는 명시적인 방법을 추가하는 것은 Jest의 유용성에 좋은 추가 사항이 될 것입니다. 이렇게 하면 다른 테스트 프레임워크(JS가 아닌 프레임워크 포함)에 익숙한 개발자가 Jest를 더 쉽게 사용할 수 있습니다.

@mattphillips 사용자 영역에 솔루션이 존재하도록 하기 위해 여기에서 jest-chain과 유사한 작업을 수행하는 것이 가능하다고 생각하십니까? 예: expect 에 대한 두 번째 인수

솔직히 이것은 대부분의 JS 테스트 프레임워크에서 매우 표준적인 것입니다. 사용자 정의 오류 메시지로 모든 테스트를 작성할 때 Jest에서 찾지 못한 것에 매우 실망했습니다.

@SimenB 죄송합니다 오늘 아침에서야 귀하의 메시지를 확인했습니다!

예, 이것은 userland에서 할 수 있습니다. 방금 jest-expect-message 로 출시했습니다. https://github.com/mattphillips/jest-expect-message

피드백 환영:미소:

굉장합니다, 해 주셔서 감사합니다!

@cpojer

이것이 별로 유용하지 않다고 생각하는 이유는 엔지니어가 테스트 작성에 시간을 낭비하고 싶지 않기 때문입니다. 그들을 더 어렵게 만들기 위해 우리가 하는 모든 일은 더 나쁜 테스트로 이어질 것입니다.

두가지:

1. 기대()에 선택적 두 번째 인수를 추가하는 것은 개발자에게 거의 어려운 일이 아닙니다.
2. 개발자가 마지막으로 하고 싶은 일은 테스트 실패의 원인을 디버깅하는 데 시간을 낭비하는 것입니다. 종종 예상 대 수신은 조건이 충족되었는지 확인하는 좋은 방법이지만 실패 원인에 대한 컨텍스트가 충분하지 않은 경우가 많습니다.

Jest에 오기 전에 Mocha/Chai와 테이프를 사용했는데 이것은 정말 거래 차단기입니다. 사용자 지정 메시지 지원을 기대하려면 어떻게 해야 합니까?

사용자 정의 매처를 생성하기 위해 expect.extend를 말하는 것은 "엔지니어는 테스트를 작성하는 데 시간을 낭비하고 싶지 않습니다."라는 첫 번째 주장에서 피하려고 했던 것과 정확히 같습니다.

나는 단위 테스트를 열고 줄 번호를 보는 것이 쉽다는 것을 알았으므로 OP의 유스 케이스는 나를 귀찮게하지 않습니다.

나를 괴롭히는 사용 사례는 예를 들어 다음과 같이 열거형의 모든 값을 테스트하기 위해 테스트 내부에 루프가 있는 경우입니다.

it("Should contain at least one word of every wordType", () => {
  for (const wordType of wordTypes) {
    expect(words.find((word) => word.wordType === wordType)).toBeTruthy();
  }
});

실패하면 어떤 wordType 값이 실패했는지 모릅니다.

내 해결 방법은 테스트 결과가 포함된 메시지로 대체하고 메시지에 예상 테스트 결과(예: true)가 포함되어 있을 것으로 예상하는 것입니다. 실패하면 Jest는 추가 정보가 포함된 메시지를 인쇄합니다.

    expect(`${wordType} ${!!words.find((word) => word.wordType === wordType)}`).toEqual(`${wordType} ${true}`);

Jest는 이것을 인쇄합니다 ...

expect(received).toEqual(expected)

Difference:

- Expected
+ Received

- 6 true
+ 6 false

... 실패했을 때 wordType이 6임을 알려줍니다.

또는 더 읽기 쉽게 ...

    if (!words.find((word) => word.wordType === wordType)) {
      expect(`Didn't find a word with wordType '${wordType}'`).toEqual(null);
    }

@cwellsx test.each 로 매개변수화된 테스트를 확인하십시오. 이렇게 하면 각 wordType이 설명적인 제목이 있는 독립적인 테스트가 됩니다(값 기반).

이것은 다음과 같은 테스트에서 매우 유용할 것입니다.

test("compare ArrayBufferCursors", () => {
    const orig: ArrayBufferCursor;
    const test: ArrayBufferCursor;

    expect(test.size).toBe(orig.size);

    while (orig.bytes_left) {
        expect(test.u8()).toBe(orig.u8());
    }
});

지금은 ArrayBufferCursor의 일부 바이트가 잘못되었다는 것만 알지만 어느 바이트인지는 모릅니다. 인덱스를 컨텍스트로 추가할 수 있으면 디버깅이 훨씬 쉬워집니다. 고맙게도 일부 사람들은 여기에 해결 방법을 제시했지만 모두 추하고 느립니다.

@rickhanlonii , 나는 당신이 jest의 유지 관리 비용을 줄이고 싶어한다는 것을 이해하지만 귀하의 의견 에서 제공하는 옵션은 다른 모든 프로젝트의 단위 테스트 유지 관리를 증가시킵니다. toEqual 를 사용하여 assertion을 설명하고 싶다면 이 정도면 충분합니다. 정말 커스텀 매처를 소개하는 건가요?!

it.each 가 유용한 반복 테스트의 경우가 있지만 주장에 대한 간단한 주석에 불필요한 코드를 추가해야 하므로 이 테스트 프레임워크를 사용하기가 더 무거워집니다.

이 토론과 jest-expect-message 의 출현은 Jasmine의 beforeAll 문제에 대해 생각나게 합니다...

여기에서 OP의 요청을 오해하고 있을 수 있지만 해결하려고 했던 문제는 간단한 try / catch 및 jest.expect 주위의 래퍼를 사용하여 해결되었습니다. 내가 하고 싶었던 모든 것은 내가 기대했던 것과 내가 받은 것들 + 그 중요성을 설명하는 몇 가지 기본 로그의 전체를 기록하는 것이었습니다. 물론 이것은 원하는 모든 작업을 수행하도록 확장될 수 있습니다.

이것의 가장 일반적인 버전은 다음과 같습니다.

in some test utility file...

const myExpect = (expectFn, errorCallback) => {
  try {
    expectFn();
  } catch (err) {
    errorCallback();
    throw new Error(err);
  }
};

// in the actual test suite...

const context = { hello: "world", results, expected };
myExpect(
    () => expect(results).toEqual(expected),
    () => console.error("[Error] -- context:", JSON.stringify(context))
);

+1
안녕하세요, 저도 이 기능을 정말 좋아합니다. 그것은 내 삶을 훨씬 더 쉽게 만들 것입니다.