[테스트] 통합 테스트 어떻게 할 것인가

[leegwae]

지금은 어떻게 테스트하고 있는가

기본적으로 Mock Service Worker로 네트워크 요청에 대한 성공 응답을 모킹하고, 테스트에서 실패 응답을 테스트하기 위해 동적으로 서버의 에러 응답을 모킹하여 오버라이딩해주고 있다.

다음은 /api/panel/:panelId 엔드포인트에 대해 성공 응답을 모킹하는 핸들러이다.

export const getPanel = rest.get<never, GetPanelPathParams, GetPanelResponse>(
 '/api/panel/:panelId',
  async (req, res, ctx) => {
    const { panelId } = req.params;
    const panel = { ...createMockPanel(), id: Number(panelId) };

    return res(
      ctx.status(200),
      ctx.json({
        statusCode: 200,
        result: panel,
      }),
    );
  },
);

해당하는 패널 정보가 없을 경우를 테스트하기 위해 다음과 같이 오버라이딩한다.

describe('/panel/:id route', () => {
  it('패널 정보 가져오기 API가 실패 응답을 반환하면 Fallback UI를 보여준다', async () => {
    overrideGetPanelResponseWithError({
      code: 'NOT_EXIST_PANEL',
      statusCode: 404,
      message: '해당 패널이 존재하지 않습니다.',
    });
    setup();

    await waitFor(() => {
      expect(screen.getByText(/존재하지 않는 패널입니다/)).toBeInTheDocument();
    });
  });
});

function overrideGetPanelResponseWithError(data: ErrorResponse): void {
  server.use(
    rest.get('/api/panel/:panelId'), async (req, res, ctx) =>
      res(ctx.status(data.statusCode), ctx.json(data)),
    ),
  );
}

아주 좋다. 테스트끼리 의존성이 없기 때문이다.

문제: Fallback UI는 어떻게 확인해야할까

그래도 개발 서버를 켜서 브라우저에서 띄워지는 Fallback UI를 확인해야하는데, 핸들러는 무조건 성공 응답을 보여주고 있어서 Fallback UI 작업할 때는 임시적으로 핸들러가 실패 응답을 보내주도록 바꿔야한다. 여간 귀찮은 게 아니다.
Fallback UI 뿐만 아니다. 만약 DELETE, POST 와 같이 멱등하지 않은 API를 호출한 다음 기대하는 UI가 있는데 성공 응답을 보여줄 뿐 mock 데이터를 수정하고 있지 않으니 해당 페이지에서는 200 응답 받고 UI에서 지워졌다한들 다른 페이지를 갔다오니 데이터가 그대로 있는 경우가 어색할 수 있다.

현재 생각나는 해결책

첫번째: mock 데이터에 실제 기대되는 로직을 수행하고 그 결과를 바탕으로 응답한다

미리 생성해놓은 mock 데이터를 기준으로 읽어주고, 수정하고, 삭제한다. (예를 들어, id가 1인 패널을 삭제해달라는 요청에 mock 데이터에 id가 1인 패널이 있으면 삭제해주고 성공 응답을, 없으면 404 Not Found 에러 응답을 해주는거다.) 그리고 afterEach로 mock 데이터를 모두 초기화한다. 좋은 거 같다. 언제나 동일한 환경에서 테스트할 수 있다.

하지만 다음과 같은 문제점이 있을 거같다.

1. 핸들러가 로직을 구현해야한다. 예를 들어 패널 생성 API 요청이 들어오면 직접 mock 데이터에 넣어줘야한다. 단순히 패널 데이터만 수정하면 괜찮은데, 만약 엔티티들끼리 엮여있다면(예를 들어 패널에 질문을 달 수 있는데 그러면 삭제된 패널에 달린 질문 mock 데이터는 어떻게 할 것인가) 모킹에 너무 힘쓰게 될 수도 있다. 물론 예시의 경우는 그냥 패널이 모두 같은 질문 mock 데이터를 공유하는 걸로 회피해볼 순 있겠다. mock 데이터끼리 의존하는 일이 없도록 하는 거다.
2. 핸들러가 성공 응답과 에러 응답 모두 모킹해야한다. 이전까지는 오버라이딩하지 않는 한 무조건 성공 응답이 오는 것을 보장할 수 있었고 에러 응답은 오버라이딩해야지만 온다는 것을 보장할 수 있었는데 이제부터는 보장할 수 없다.
3. 모든 경우의 수를 고려할 수 없으므로 핸들러가 커버하지 않는 응답에 대한 UI는 여전히 볼 수 없다.

일반적인 성공 응답(아마 200)과 일반적인 실패 응답(아마 404 Not Found)만 모킹하는 것을 고려하면, 시도는 해볼 수 있을 거 같다. 그 외의 실패 응답 UI를 어떻게 브라우저에서 띄워볼 지는 생각을 해봐야겠다.

두번째: 통합 테스트에 msw 말고 다른 테스트 프레임워크를 사용한다

이 옵션은 아직 잘 모른다, 다른 테스트 프레임워크를 써보지 못했다. 이건 조사해 봐야겠다.