믿음으로 가는 Jest

Jest

NestJs에서는 기본적으로 테스팅 툴인 Jest 프레임워크와 @nestjs/testing이라는 패키지를 제공해줍니다.

그래서 NestJs를 사용하면 별도의 서칭 없이 Jest를 사용하여 테스트를 진행할 수 있습니다.

이 글에서는 Jest를 통한 여러가지 테스트 기법과 Coverage에 대해 설명하겠습니다.

테스트코드

테스트는 중요하고 장점도 매우 많습니다.

일단 개발자 자신에게 안정감을 안겨준다는 점이 가장 크다고 생각하고 이는 코드의 안정성 증가, 생산성을 높여줄 수 있습니다.

리팩토링 시 처음부터 전부 테스트 할 필요 없이 변경된 부분만 테스트를 진행할 수 있습니다.

또한 테스트 문서를 대체할 수도 있습니다.

장점도 많지만 단점도 존재하는데, 생각보다 시간이 오래 걸리는 점이 단점 중 하나입니다.

해보신 분이라면 아시겠지만, 서비스를 구현하는 것보다 그 서비스에 대한 테스트 진행, 예외케이스 생성 등 테스트코드를 짜는 시간이 더 오래 소요됩니다.

테스트끼리의 의존성이 강하게 결합한다거나 하는 코드가 생기면 디버깅이 오히려 더 힘들어질 수도 있습니다.

하지만 단점보다는 장점이 훨씬 더 많다고 생각합니다.

테스트 구성 (spec.ts)

위에서 말씀드린것처럼 NestJs는 @nesting/testing 패키지를 제공합니다.
이 패키지를 사용하여 app을 만들어 주고 database의 경우 sqlite3를 사용합니다.
insert, update test를 실행해야 하기 때문에 실제 db는 사용하지 않습니다.
유닛 테스트를 진행할 때는 controller를 호출해서 테스트하므로 app에서 controller를 가져와서 할당해줍니다.

import {Test, TestingModule} from '@nestjs/testing';
describe('WonderwallController', () => {
    let app = TestingModule;
    // ...
    beforeAll(async () => {
        app = await Test.createTestingModule({
            imports: [
                LoggerModule.forRoot(),
                ConfigModule.forRoot({
                    load: [configuration],
                    cache: true,
                    isGlobal: true
                }),
                TypeOrmModule.forRoot({
                    type: 'sqlite',
                    database: ':memory:',
                    autoLoadEntities: true,
                    synchronize: true,
                    logging: false
                }),
                WonderwallModule
            ]
        });

        wonderwallController = app.get(WonderwallController);
    });
});

테스트 구성 (seed.ts)

테스트를 진행할 때 수많은 케이스들이 존재합니다. 예를 들어 아래의 코드만 봐도 이 한줄에만 케이스가 4가지나 나오게 됩니다.

if (!episode.is_free && !(await this.episodeRepository.hasAccessibility(vod.id, userId))) throw new UnauthorizedException();

이런 여러 케이스를 테스트하기 위해선 데이터를 한번 만들고 그 데이터를 계속 사용하는 게 아니라, 케이스별로 데이터를 분리해서 생성하고 삭제하기를 반복합니다.
그래서 seed.ts라는 파일을 만들고, 이 파일 내부에 아래처럼 해당 케이스에 필요한 모든 데이터들을 생성해놓는 곳으로 활용했습니다.

- seed.ts
// 에피소드가 유료인 경우 + 권한이 없는 경우 -> 실패 케이스의 데이터
export const seedGetVodEpisodeVideoPaidVodAndNotAccessible = {
    stage: (): Partial<Stage> => ({
        title: 'stage title ',
        // ...
    }),
    stageVod: (stageId: number): Partial<StageVod> => ({
        title: 'stage_stageVod_title',
        // ...
    }),
    stageVodEpisode: (stageVodId: number): Partial<StageVodEpisode> => ({
        title: 'stage_vod_episode_title',
        // ...
};

아래는 테스트 파일입니다.
테스트 케이스(it)별로 데이터를 생성하고 테스트가 끝나면 데이터를 삭제합니다.
이러한 방법을 사용하면 여러 케이스를 매우 정확하게 테스트할 수 있다는 장점이 있습니다.

// 유료인 경우 + accessible이 없는 경우 -> 실패
it('should return UnauthorizedException if vod is not free and user does not have accessibility', async () => {
    // 테스트 전 데이터 생성
    stage = await connection.getRepository(Stage).save(seedGetVodEpisodeVideoPaidVodAndNotAccessible.stage());
    // ..

    // 테스트 실행
    await expect(episodeController.getVodEpisodeVideo(me[0], {episodeId: stageVodEpisode.id})).rejects.toThrow(UnauthorizedException);

    // 테스트 이후 데이터 삭제
    // ..
    await connection.getRepository(Stage).clear();
});

Api test

아래 코드는 예시로 만든 원더월의 클래스를 모두 조회하는 GET API의 쿼리 부분입니다.

getClasses(offset: number, limit: number) {
        return this.connection
            .getRepository(Class)
            .createQueryBuilder('class')
            .orderBy({'class.num': 'DESC'})
            .take(limit)
            .skip(offset)
            .getMany();
    }

조회 api에서 주로 테스트 할 내용은 2가지입니다.

1. offset, limit
2. order by asc, desc

테스트에 앞서 seed.ts에 해당 테스트를 위한 데이터를 먼저 생성합니다.
order by 테스트는 데이터 한두개로 진행하기에 신뢰도가 매우 떨어지기 때문에 아래와 같이 클래스 100개를 생성합니다.
id는 auto increments이므로 자동 생성됩니다.

export const seedClasses: Partial<Class>[] = [...new Array(100).keys()].map(i => ({
    title: `title_${i}`,
    num: Math.floor(Math.random() * 50),
    active: i % 3 === ? 'active' : 'inactive'
}));

데이터를 만들었으니 테스트를 진행합니다.
첫번째로 offset, limit이 querystring으로 전달되는데 올바르게 작동하는지 테스트합니다.
아래에선 offset: 0, limit: 7 이므로 result의 길이는 7이 되야 합니다.

it('should return classes according to offset, limit', async () => {
    const result = await wonderwallController.getClasses({offset: 0, limit: 7}); // 7개를 가져온다.

    expect(result).toBeDefined();
    expect(result).toHaveLength(7); // result의 length는 7
    // ...
});

두번째는 num desc 정렬이 올바르게 되는지 테스트합니다.
api 호출의 결과인 result의 id로 우리가 만든 테스트 데이터에서 class를 하나씩 찾습니다.
result는 num desc 정렬이기 때문에 for문 내부에서 result의 id로 찾은 class를 하나씩 비교하면
현재 데이터의 num이 다음 num보다 크거나 같아야 합니다.

it('should return classes order by id desc', async () => {
    const result = await wonderwallController.getClasses({offset: 0, limit: 9});

    for (let i = 0; i < result.length - 1; i++) {
        const currentClass = seedClasses.find(({id}) => id === result[i].id);
        const nextClass = seedClasses.find(({id}) => id === result[i + 1].id);

        expect(currentClass!.num).toBeGreaterThanOrEqual(nextClass!.num);
    }
    // ...
});

만약 order by column이 여러개라면 전부 테스트를 진행해 주는 것이 좋고
header나 param의 존재여부에 따라 api의 작동이 달라지게 된다면 이 또한 테스트를 진행해주는 것이 안전합니다.

SpyOn

Jest의 장점 중 하나는 mock 기능을 제공한다는 것입니다.

jest.spyon() 함수를 사용해서 가짜 함수를 생성할 수 있는데,

주로 함수의 동작을 다르게 하거나, 실제로 실행되면 안되는 함수에 대해 적용합니다.

에러가 발생했을 때 슬랙을 전송해주는 함수가 있다면, 테스트가 실행될 때는 전송할 필요가 없으므로 아래처럼 작업합니다.

const spySlack = jest.spyOn(wonderwallService, 'sendSlackFunction').mockImplementation(() => Promise.resolve());

wonderwallService의 sendSlackFunction()의 동작을 변경, 실행만 하고 아무 작동을 하지 않게 변경해줍니다.
spyon으로 함수를 mocking했다고 해당 함수가 실행되지 않는 것은 아닙니다.
그러므로 해당 함수가 실행되었는지 테스트하는 것이 정확한 테스트입니다.
toBeCalled, toBeCalledTimes 등의 함수를 사용하여 함수가 호출되었는지를 테스트할 수 있습니다.

expect(spySlack).toBeCalledTimes(1);

jest에서는 흔히 생각하는 function 말고 많은 것을 mocking할 수 있습니다.
아래는 특정 조건에서 로그를 찍는 코드입니다. !wonderwall일때 logger.info가 올바르게 작동하는지도 확인할 수 있습니다.

if (!wonderwall) return this.logger.info('no wonderwall!');

jest.fn()을 사용하여 가짜 함수인 loggerMock을 생성합니다.
우리가 원하는 logger.info의 값이 올바르게 출력되는지 확인하려면 logger.info의 동작을 변경하여 테스트가 가능하도록 해야합니다.
그래서 logger.info의 반환값을 위에서 만든 loggerMock으로 대체도록 할건데, mockImplementation 안에서 loggerMock을 즉석으로 구현할 수 있습니다.
loggerMock을 message 파라미터를 받아 출력하는 함수로 구현합니다. 이러면 logger.info가 올바른 message를 출력하는지 테스트할 수 있습니다.
여기서 message는 logger.info의 파라미터입니다.

const loggerMock = jest.fn();

const loggerInfoMock = jest.spyOn(wonderwallService['logger'], 'info').mockImplementation(message => loggerMock(message));

// api 실행 ...

expect(loggerInfoMock).toBeCalledWith('no wonderwall!');

테스트 커버리지

테스트 커버리지란 전체 코드 중 테스트가 된 부분과 안된 부분을 전부 종합해서 그 비율을 알려주는 기능입니다.
저희는 package.json에 script를 등록해서 사용합니다.

"script": {
    "test:cov": "jest --coverage"
}

아래 사진은 원더월 백엔드 레포지토리중 하나의 테스트 커버리지입니다.
리포트를 보면 Stmts, Branch, Funcs, Lines, Uncovered Line 5가지가 존재합니다.

• Stmts와 Lines는 비슷합니다. 전체 명령문이 얼마나 수행되었는지 보여줍니다.
• Branch는 전체 코드의 분기문에 대한 실행 결과를 보여줍니다.
• Funcs 전채 코드의 함수 실행에 대한 결과를 보여줍니다.
• Uncovered Line는 테스트가 실행되지 않은 라인을 알려줍니다. 개인적으로 테스트할때 가장 중요하게 봐야하는 부분이라고 생각합니다.

마치며

원더월 백엔드 팀은 테스트를 중요시합니다.
테스트 코드에서 최대한 예외를 잡아내고, 실제 환경에서 하기 힘든 테스트를 구현하려 노력합니다.
대부분의 레포지토리가 커버리지 90퍼 이상을 유지하고 있으며 다양한 테스트 기법을 도입하고, 더 좋은 방법을 항상 찾아가고 있습니다.
물론 테스트 코드가 모든 에러와 예외를 잡아내지는 못합니다. 하지만 본인이 작성한 코드에 대한 의도된 테스트를 정확하게 할 수 있다는 점이 큰 장점이기 때문에 시간이 좀 걸리더라도 테스트에 많은 시간을 사용하며 업무를 진행하고 있습니다.

앞으로도 원더월 개발팀의 다양한 업무소식을 전해드리겠습니다. 많은 기대 부탁드립니다.

감사합니다.