프로젝트의 황무지

우리는 비즈니스 코드의 품질에만 집중하고 단위 테스트 코드 품질을 무시했습니다. 그것은 단위 테스트 코드를 우리 프로젝트의 서부 지역이 되게 합니다. 그래서 나는 내 프로젝트에서 사용한 몇 가지 연습을 공유할 것입니다.

코드 스타일로 시작

먼저 단위 테스트 코드의 스타일부터 시작하겠습니다. 우리는 비즈니스 코드에 eslint를 사용했습니다. 하지만 농담 코드에 eslint를 사용해 보셨습니까? eslint-plugin-jest 을(를) 시도하십시오. 이 패키지의 소개는 다음과 같습니다. https://www.npmjs.com/package/eslint-plugin-jest

다음은 내 프로젝트에서 사용한 규칙 집합입니다.

'jest/expect-expect': 'error',
'jest/lowercase-name': [
    'error',
    {
        ignore: ['describe'],
    },
],
'jest/no-disabled-tests': 'error'
'jest/no-done-callback': 'error',
'jest/no-duplicate-hooks': 'error',
'jest/no-conditional-expect': 'error',
'jest/no-export': 'error',
'jest/no-focused-tests': 'error',
'jest/no-identical-title': 'error',
'jest/no-interpolation-in-snapshots': 'error',
'jest/no-jasmine-globals': 'error',
'jest/no-jest-import': 'error',
'jest/no-large-snapshots': 'error',
'jest/no-mocks-import': 'error',
'jest/no-standalone-expect': 'error',
'jest/no-test-prefixes': 'error',
'jest/valid-describe': 'error',
'jest/valid-expect-in-promise': 'error',
'jest/prefer-to-have-length': 'warn',
'jest/valid-expect': 'error',

대부분 이해하기 쉽습니다. 그러나 나는 그들 중 일부를 소개하고 싶습니다.

농담 / 완료되지 않은 콜백

습관을 바꿔야 할 수도 있습니다. 더 이상 done를 사용하지 마십시오. 코드가 done에 도달할 수 없으면 쉽게 오류가 발생하기 때문입니다. 또한 콜백을 사용하는 것은 테스트에서 어설션이 작동하는 방식에 대한 주의 깊은 이해가 필요하기 때문에 매우 취약할 수 있습니다. 그렇지 않으면 테스트가 예상대로 작동하지 않습니다.

테스트 작성 방법을 변경해야 하는 2가지 시나리오가 있습니다.

비동기 작업을 위해

비동기 작업의 경우. 완료 대신 사용async...await으로 전환합니다. 또는 다음과 같이 약속을 반환할 수 있습니다.

return doSomething().then(data => {...})

setTimeout에 대해

setTimeout . 테스트 파일의 시작 부분에 jest.useFakeTimers()를 사용하십시오. 그런 다음 jest.runAllTimers()를 사용하여 모든 타이머가 실행될 때까지 빨리 감기

타이머 모커에 대한 자세한 내용은 https://jestjs.io/docs/timer-mocks 을 참조하십시오.

농담/무조건 기대

조건부 호출에서 expect를 사용하면 expect가 자동으로 건너뛸 수 있습니다. expect에 catch를 넣어도 건너뛰기 쉽습니다.

다음 패턴은 경고입니다.

it ('foo', () => {
    const result = doSomething();
    if (result === 1) {
        expect(1).toBe(1)
    }
})

it ('bar', () => {
    try {
        await foo();
    } catch (err) {
        expect(err).toMatchObject({ code: 'MODULE_NOT_FOUND' });
    }
})

이 테스트를 이런 방식으로 작성하는 것이 좋습니다.

it ('foo', () => {
    const result = doSomething();
    expect(result).toBe(1);
    expect(1).toBe(1);
})

it ('throws an error', () => {
    await expect(foo).rejects.toThrow(Error);
})

농담 / 동일하지 않은 제목

중요한 규칙이 있습니다no-identical-title. 2개의 테스트 케이스를 같은 이름으로 명명하는 것을 방지하기 위함입니다.

다음 패턴은 경고로 간주됩니다.

it('should do bar', () => {});
it('should do bar', () => {}); // Has the same title as the previous test

간단하지만 매우 유용합니다. 실패한 단위 테스트를 수정하려고 시도한 경험이 있습니다. 그러나 문제 해결 30분 후에도 여전히 실패했습니다. 그런 다음 나는 실패한 것을 고치고 있지 않다는 것을 발견했습니다. 같은 이름의 실패한 단위 테스트가 2개 있는 경우 특히 까다롭습니다.