jest-puppeteer 를 사용하면 커버리지 측정이 안된다!

서론

최근 trackpurchase 라는 프로젝트를 진행 중이다. 다양한 쇼핑 플랫폼에서 결제기록을 한번에 조회 할 수 있고, 또 쉽게 확장해서 원하는 플랫폼의 크롤러를 구현 할 수 있도록 돕는 npm 라이브러리이다.
기술 스택은 다음과 같다.

• puppeteer
• jest
  • jest-puppeteer

사실 JS / TS 를 사용해 프로젝트를 진행한 경험이 거의 없어서, 각 기술스택을 고를 때는 가장 많이 사용되고 있는 라이브러리들을 골랐다.
그런데.. 아래와 같은 문제가 발생했다.

 

[cov 사진]

아니  cov_  로 시작하는 selector 를 사용한 코드가 전혀 없는데 왜 이러지?

나는 공식 문서를 제대로 읽지 않은 죄로 이틀을 날리게 되었다..

본론

공식 문서만 봐도 한번에 알 수 있는 내용이긴하다. 그런데 그 공식 문서를 꼼꼼히 못본 탓에 놓쳤어서 이렇게 기록해둔다.
공식 문서의 맨 위를 보면 이렇게 적혀잇다.

Generating code coverage for test files using Puppeteer is currently not possible if your test uses page.$eval, page.$$eval or page.evaluate as the passed function is executed outside of Jest's scope. Check out issue #7962 on GitHub for a workaround.

만약 테스트가 page.$eval, page.$$eval, page.evaluate 중 하나를 사용한다면, 앞에서 언급한 함수로 넘겨진 함수가 Jest 의 Scope 를 벗어납니다. 따라서 Puppeteer 를 사용하는 테스트 파일이 있을 경우 코드 커버리지를 생성하는것은 현재로썬 불가능합니다. issue #7692 에서 진행 상황을 확인할 수 있습니다.

 

 

해당 이슈를 보니 다들 관심을 갖고 바라보진 않는것 같다. 나의 경우는 해당 이슈에서 소개하는 임시 방편(?) 을 사용했는데, jest config 에다가 coveragePathIgnorePatterns 인자값의 내용으로 해당 파일을 지정해주면 된다. 예를 들면, 나는 jest.config.ts 에 다음과 같이 적어두었다. (문제가 되는 파일명이 elementParser.ts 였다.)

import type { Config } from "@jest/types";

// Sync object
const config: Config.InitialOptions = {
  preset: "jest-puppeteer",
  coveragePathIgnorePatterns: ["elementParser.ts"],
};
export default config;

마치며

웹 크롤러를 작성해 테스트를 하는것은 꽤 흔한것으로 알고있는데, 웹 크롤러 자체를 테스트 하는 경우는 많이 없는것같다. 그래서 많은 시행착오를 겪고있다. 테스트를 작성할때는 보통 given, when, then 의 세 요소로 작성하는데, 각각 테스트를 위해 주어진 환경(given), 테스트를 진행할 내용(when), 그리고 그 이후에 동작해야 하는 내용(then) 으로 작성한다.

보통 이런식으로 외부서비스와 연계되는 부분을 작성할때의 테스트는 해당 외부서비스 부분을 mocking 을 진행한다. 그런데 이번 프로젝트를 진행하며 네이버에 로그인 시키는 함수에 대한 테스트를 작성하기 위해 내가 했었던 고민들은 다음과같다.

1. 직접 내 계정을 사용해야하나?
2. 그렇지 않다면, 해당 페이지 내의 로그인 부분의 코드를 임의로 수정해야하나? 그렇다면 매번 테스트를 작성할때마다 해당 페이지가 어떻게 동작하는지 분석하느라 너무 시간이 오래걸릴거같은데?
3. 그렇지 않다면, puppeteer 내의 객체들을 mocking 해야 하나? 이렇게 되면 연계되는 외부 서비스(네이버)를 내가 원하는 동작을 만들도록 상태를 변경하는게 아니라, 그냥 그 사이에 있는 매개체(puppeteer)가 내가 원하도록 동작을 바꾸는건데, 이렇게 작성된 테스트가 의미가 있을까?
   • ex) 네이버의 로그인 함수를 mocking 하는게 아니라, 로그인 함수 버튼을 클릭하는 puppeteer 함수를 mocking

하는, 그런 고민들을 했고, 지금도 하고있다. 가장 바람직한것은 2로 보이나 사실 사이트 구조가 바뀌게 되면 2던 3이던 작동을 멈춘다는 면에서 일단은 보통 3으로 생각하고 테스트 코드를 작성하고 있다.
나는 개인프로젝트니까 이렇게 넘기지만, 프로덕션에서 사용하는 다른 조직이나 팀에서는 어떻게 대응하는지 궁금하다.