실무에서의 테스트 절차

[906bc906]

궁금한 것

아직 보일러 플레이트 제작중이라 웹팩과 바벨을 프로젝트에 올리진 않았는데요,

진행중인 프로젝트에서 웹팩을 이용해서 번들링할 때 테스트하는 절차가 잘 그려지지가 않습니다.

현재

현재 프로젝트가 동작하고 있는 방식입니다.

백엔드로 Express, 프론트엔드로 Pug template을 사용하여 템플릿 엔진은 Express의 하위에서 동작하고 있습니다.

0. 유저가 Express에 페이지 요청을 보내면,
1. 백엔드가 요청을 받고 프론트엔드에 전달하고,
2. 프론트엔드는 필요한 PUG를 렌더링하여,
3. 렌더링된 HTML를 유저에게 전송합니다. (전송은 백엔드가 하고 그 이후에 html을 받은 유저의 추가적인 요청으로 css, js 전송이 이뤄지겠으나 간략화하였습니다)

webpack 추가

public 디렉토리에 있던 파일들을 sources와 views 디렉토리로 분리한 뒤

여러 자바스크립트 모듈들과 JS로 전환된 CSS가 JS파일로 번들링되고,

웹팩을 이용하여 html webpack plugin으로 번들링된 js 추가 구문이 삽입된 pug이 public 폴더에 출력됩니다.

• [ ] 디렉토리 구조가 이게 맞는지 모르겠습니다. 특히 views 디렉토리와 public 디렉토리의 관계가 되게.. 이상하다고 느껴져요. 그렇다고 원본 pug 파일들을 sources로, 출력 pug를 views로 옮기는 것도 뭔가 좀 이상하네요.
• [ ] 구간마다 필요로 하는 js 및 css가 다를 거라고 생각합니다. /search.html 과 /main 이 아예 겹치는 애셋이 없는 경우도 있을 수 있을 것 같습니다. 그럼에도 불구하고 단 하나의 js 파일로 번들링해야되는지? 그렇지 않다면 각 페이지별로 웹팩의 entry 와 output을 다 따로 잡아줘야 하는데 이것도 굉장히 번거롭다는 느낌을 받습니다.
• [ ] 매번 변경할 때마다 수동으로 번들링하는 것이 번거롭기 때문에 방법을 찾아보니 npx webpack --watch 를 쓰는 방법과 webpack-dev-server를 쓰는 방법이 있는 것 같습니다. 성능은 후자가 더 좋아보이는데, 제 프로젝트가 SSR로 동작하기 때문에 webpack-dev-server 에 writeToDisk 옵션을 활성화(dev-server가 기본적으로는 메모리 위에서 동작해서 파일 저장하게끔 지시하기 위해)하는 것과 npx webpack --watch를 저울질 하려고 합니다. 터미널을 두개 띄우고 하나는 웹팩 번들링 자동화(dev-server 또는 --watch), 다른 하나는 express 백엔드가 동작하도록 하고 브라우저로는 express 백엔드 서버에 접속하는 식으로 테스트할 듯 한데, 혹시 다른 더 좋은 방안이 있는지 궁금합니다.

[blueStragglr]

"테스트" 라는 것은 작성한 코드를 실행하고 확인하는 의미로 하신 말씀이실까요? 아니면 Unit test나 E2E 테스트같은 것들을 말씀하신 것일까요? 일단 글의 내용을 보았을 때에는 전자인 것 같아서 로컬에 웹페이지를 서빙하고 사용하는 방식에 대해서 작성드립니다.

1. 디렉토리 구조는 정답이 없습니다. 프론트엔드 어플리케이션의 성격에 따라서 프로젝트가 모노레포로 구성되기도 하고, MSA가 되기도 하고, 단일 엔트리포인트를 같은 CSR이 되기도 합니다. 디렉토리 구조와 빌드 파이프라인은 각 프로젝트의 필요에 따라 결정하게 되며, 정답이 있는 부분은 아닙니다. 지금의 프로젝트 (검색과 목록을 보여주는 서비스형 웹 어플리케이션) 에 대해서 생각하고 현재의 구조적 문제를 생각해 보자면, "pug 출력 파일이 public에 저장된다" 부분이 가장 문제인 것 같네요. 프론트엔드 프레임워크를 통해서 빌드된 파일들은 일반적으로 git에 의해 추적되지 않고, 배포 및 서빙시에만 사용합니다.

• public에는 정적으로 사용하는 에셋 (이미지, 폰트 등)과 HTTP entry를,
• views에는 라우터에 의해 호출될 페이지 루트 컴포넌트들을
• components에는 라우터에 의해 호출되거나 서로 호출하는 컴포넌트들을,
• api에는 api 관련 동작이나 유틸들을 주로 담습니다.

번들 및 빌드 결과물은 dist나 build 폴더에 주로 생성되며, 서빙 시에만 이용됩니다.

2. 구간마다 필요한 JS나 CSS만 로드할 수도 있습니다. 다만, 말씀대로 웹팩에서 개별 라우터에 해당하는 파일들을 모두 작성하거나 lazy load하도록 설정하는 것은 너무 복잡하고 커다란 일입니다. 그렇다 보니 프론트엔드 프레임워크들은 Next.js, Nuxt.js같은 SSR 라이브러리를 제공하며, SSR 라이브러리의 static build를 실행하면 각 엔트리포인트에 필요한 파일을 개별 번들링하고 전달합니다. static build 없이 서버사이드에서 렌더링하는 경우에도 각 페이지에서 요구하는 리소스만 내려주게 됩니다. 일반적으로 해당 작업은 수동으로 진행하지 않습니다.

3. 말씀하신 대로 터미널을 두 개 띄우고 hot reload가 가능한 상태로 클라이언트를 실행하고, 서버를 로컬에 띄운 상태로 한쪽을 수정하면서 작업하는것이 일반적인 개발 프로세스입니다.