[Node.js] Jest 경로 전쟁: 복잡한 설정 대신 구조로 해결하기

---

Jest 경로 전쟁: 복잡한 설정 대신 구조로 해결하기

테스트 코드를 작성할 때, ../가 반복되는 상대 경로 문제는 개발자를 괴롭히는 오랜 숙적과 같다. 우리는 종종 이 문제를 해결하기 위해 jest.config.js의 moduleNameMapper와 같은 복잡한 설정의 세계로 뛰어들지만, 때로는 그 길이 더 큰 혼란으로 이어지기도 한다. 이 글에서는 복잡한 설정과의 사투 끝에, 파일 구조를 변경하는 단순한 발상의 전환이 어떻게 더 우아하고 안정적인 해결책이 되었는지 그 경험을 공유하고자 한다.

1. 문제의 시작: 테스트 파일과 데이터의 분리

프로젝트 초기에는 보통 기능 코드와 테스트 코드를 분리하여 관리한다. 예를 들어, Express 애플리케이션을 테스트하기 위해 다음과 같은 구조를 가질 수 있다.

1-1. 일반적인 프로젝트 구조

• 루트 디렉토리 구조
  프로젝트의 최상위 레벨에 __tests__ 디렉토리와 테스트에 사용할 mock-data 디렉토리를 분리하여 위치시키는 것은 흔한 패턴이다.

  /
  ├── __tests__/
  │   └── api.test.js
  ├── mock-data/
  │   └── user.json
  ├── src/
  │   └── app.js
  └── package.json

1-2. 복잡한 상대 경로의 출현

• api.test.js의 내용
  이 구조에서 api.test.js가 app.js와 user.json을 가져오려면 ../를 사용하여 상위 디렉토리로 이동해야 한다.

  // __tests__/api.test.js
  const request = require("supertest");
  const app = require("../src/app"); // 상위로 한번, src로 진입
  const mockUser = require("../mock-data/user.json"); // 상위로 한번, mock-data로 진입
  
  // ... 테스트 코드

  이 코드는 당장은 동작하지만, 프로젝트가 커지면 경로가 훨씬 더 복잡해지고 유지보수가 어려워지는 잠재적인 폭탄이 된다.

2. 발상의 전환: "어떻게 설정할까?"에서 "어디에 둘까?"로

이 경로 문제를 해결하기 위해 moduleNameMapper 같은 설정과 오랜 시간 씨름했지만, 환경에 따른 미묘한 차이와 설정 자체의 복잡성으로 인해 계속해서 실패했다(정확히 말하자면 Cursor AI가...). 여기서 한 걸음 물러나 문제의 본질을 다시 생각하게 되었다. "복잡한 경로를 어떻게 짧게 만들까?"가 아니라, "애초에 경로가 복잡하지 않게 하려면 파일을 어디에 두어야 할까?"로 관점을 바꾼 것이다.

2-1. 해결책: 테스트 자산(Asset)을 테스트와 함께 두기

• 핵심 아이디어
  테스트를 실행하는 데에만 사용되는 파일(테스트 데이터, 모의 객체 등)은 해당 테스트 파일과 가장 가까운 곳에 위치시키는 것이 가장 직관적이다.

• 파일 구조 변경
  mock-data 디렉토리를 __tests__ 디렉토리 안으로 옮겨보자.

  /
  ├── __tests__/
  │   ├── mock-data/
  │   │   └── user.json
  │   └── api.test.js
  ├── src/
  │   └── app.js
  └── package.json

2-2. 마법처럼 단순해진 코드

• 수정된 api.test.js
  이제 user.json을 가져오는 경로는 매우 단순하고 명확해진다.

  // __tests__/api.test.js
  const request = require("supertest");
  const app = require("../src/app"); // 이 경로는 여전히 필요하다.
  const mockUser = require("./mock-data/user.json"); // 매우 직관적인 경로!
  
  // ... 테스트 코드

  app.js와 같이 여러 테스트에서 공유하는 핵심 모듈의 경로는 그대로 두더라도, 각 테스트에 종속적인 데이터의 경로가 단순해진 것만으로도 코드의 가독성과 안정성은 크게 향상된다.

결론: 때로는 가장 단순한 해결책이 최고이다

우리는 종종 기술적인 문제를 해결하기 위해 더 복잡하고 강력한 도구를 찾으려는 경향이 있다. 하지만 이번 경험은 우리에게 중요한 교훈을 주었다. 복잡한 설정과의 싸움에 시간을 허비하기 전에, 한 걸음 물러나 문제의 구조 자체를 바꿀 수는 없는지 고민해볼 필요가 있다는 것이다.

Jest의 경로 문제 역시 마찬가지이다. moduleNameMapper는 분명 훌륭한 기능이지만, 파일을 적절한 위치로 옮기는 간단한 구조적 변경이 때로는 그 어떤 복잡한 설정보다 더 우아하고 효과적인 해결책이 될 수 있다. 결국 좋은 설계란, 복잡한 문제를 푸는 것뿐만 아니라 문제를 단순하게 만드는 지혜에서 비롯되기 때문이다.

---