[JSTS-010][실무] 테스트·검사·코드 정리를 한 번에 실행하기
페이지 정보

본문
[이번 수업]
JavaScript 프로젝트의 테스트, 린트, 포맷 검사를 한 명령으로 묶습니다. 린트는 코드를 실행하지 않고 규칙 위반과 위험한 패턴을 찾는 정적 검사이고, 포맷은 들여쓰기와 줄바꿈을 일정하게 정리하는 작업입니다.
[선수지식]
Node.js와 npm, ES 모듈의 `import`·`export`, 함수 작성법을 알아야 합니다. 터미널에서 폴더를 만들고 파일을 저장할 수 있어야 합니다.
[학습목표]
1. 테스트·린트·포맷의 역할을 구분합니다.
2. package.json의 scripts로 검사 명령을 표준화합니다.
3. 로컬과 자동화 환경에서 같은 검사를 실행합니다.
[핵심개념]
테스트는 입력에 대해 프로그램이 기대한 결과를 내는지 확인합니다. Node.js에는 `node:test` 모듈과 `node --test` 실행기가 들어 있습니다. 린터는 선언하지 않은 변수처럼 오류 가능성이 있는 코드를 규칙으로 찾습니다. 포매터는 코드 의미를 바꾸려는 도구가 아니라 표현 형식을 일관되게 맞춥니다. TypeScript 프로젝트라면 `tsc --noEmit`을 추가해 파일을 만들지 않고 타입만 검사할 수 있습니다.
각 도구를 직접 외우기보다 `npm run test`, `npm run lint`, `npm run format:check`처럼 프로젝트 명령으로 고정합니다. `check` 스크립트는 이들을 순서대로 묶어 하나라도 실패하면 성공으로 끝나지 않게 합니다. 개발자 컴퓨터와 지속적 통합 환경이 같은 `npm run check`를 쓰면 검사 차이를 줄일 수 있습니다. 지속적 통합은 변경할 때마다 빌드와 검사를 자동 실행하는 방식입니다.
검사 도구는 프로젝트의 `devDependencies`에 기록하고 잠금 파일도 함께 관리해야 팀이 같은 버전을 설치하기 쉽습니다. 포맷 수정 명령과 확인 명령을 분리합니다. `format`은 파일을 바꾸고 `format:check`는 바꾸지 않은 채 차이만 알려 주므로 자동 검사에는 후자가 알맞습니다.
[따라하기]
빈 폴더에서 macOS·Linux 터미널이나 Windows PowerShell로 다음을 실행합니다. 명령은 세 운영체제에서 같습니다.
```sh
mkdir quality-demo
cd quality-demo
npm init -y
npm pkg set type=module
npm install --save-dev eslint @eslint/js prettier
npm pkg set scripts.test="node --test"
npm pkg set scripts.lint="eslint ."
npm pkg set scripts.format="prettier --write ."
npm pkg set scripts.format:check="prettier --check ."
npm pkg set scripts.check="npm run test && npm run lint && npm run format:check"
```
math.js를 만듭니다.
```javascript
export function add(a, b) {
return a + b;
}
```
math.test.js를 만듭니다.
```javascript
import assert from "node:assert/strict";
import test from "node:test";
import { add } from "./math.js";
test("두 수를 더한다", () => {
assert.equal(add(2, 3), 5);
});
```
eslint.config.js를 만듭니다.
```javascript
import js from "@eslint/js";
export default [js.configs.recommended];
```
`npm run check`를 실행합니다. 버전에 따라 전체 출력 모양은 달라도 테스트의 통과 수가 1이고, 린트 오류가 없으며, 포맷 검사에 모든 대상 파일이 형식에 맞는다는 결과가 나오면 성공입니다. `math.js`의 세미콜론을 지운 뒤 `npm run format:check`로 실패를 확인하고 `npm run format`으로 고친 다음 다시 검사합니다.
[흔한 실수]
포맷 검사 통과를 동작 검증으로 오해하거나 테스트 하나만 통과하면 전체가 안전하다고 생각하면 안 됩니다. 전역 설치된 도구에 의존하면 컴퓨터마다 버전이 달라질 수 있습니다. 자동 수정 뒤에는 반드시 변경 내용을 검토하고 테스트를 다시 실행합니다.
[보안 주의]
설치 전에 패키지 이름과 출처를 확인하고 잠금 파일의 예상하지 못한 변경을 살핍니다. 검사 로그나 테스트 데이터에 토큰·개인정보를 넣지 않습니다. 린트와 테스트는 보안 검토를 완전히 대신하지 못합니다. 실습은 본인 소유의 로컬 또는 허가된 격리 환경에서 수행합니다.
[직접 해볼 과제]
`subtract(a, b)` 함수와 정상·음수 결과 테스트를 하나씩 추가하세요. 일부러 기대값 하나를 틀리게 해 `npm run check`가 중단되는지 확인한 뒤 올바르게 고칩니다.
[확인문제]
1. 테스트, 린트, 포맷 검사는 각각 무엇을 확인하나요?
2. 자동 검사에서 `format`보다 `format:check`가 알맞은 이유는 무엇인가요?
3. 도구를 devDependencies에 기록하는 이유는 무엇인가요?
[다음 학습]
다음 과정 WEB-010에서는 웹 성능과 Core Web Vitals를 측정하고 개선합니다. JSTS-011에서는 JavaScript 입력 검증과 보안을 다룹니다.
[공식 참고 자료]
- Node.js 테스트 실행기: https://nodejs.org/api/test.html
- npm scripts 공식 문서: https://docs.npmjs.com/cli/v11/using-npm/scripts
- ESLint 시작 안내: https://eslint.org/docs/latest/use/getting-started
- ESLint 설정 파일: https://eslint.org/docs/latest/use/configure/configuration-files
- Prettier CLI 공식 문서: https://prettier.io/docs/cli
- TypeScript 컴파일러 옵션: https://www.typescriptlang.org/docs/handbook/compiler-options.html
JavaScript 프로젝트의 테스트, 린트, 포맷 검사를 한 명령으로 묶습니다. 린트는 코드를 실행하지 않고 규칙 위반과 위험한 패턴을 찾는 정적 검사이고, 포맷은 들여쓰기와 줄바꿈을 일정하게 정리하는 작업입니다.
[선수지식]
Node.js와 npm, ES 모듈의 `import`·`export`, 함수 작성법을 알아야 합니다. 터미널에서 폴더를 만들고 파일을 저장할 수 있어야 합니다.
[학습목표]
1. 테스트·린트·포맷의 역할을 구분합니다.
2. package.json의 scripts로 검사 명령을 표준화합니다.
3. 로컬과 자동화 환경에서 같은 검사를 실행합니다.
[핵심개념]
테스트는 입력에 대해 프로그램이 기대한 결과를 내는지 확인합니다. Node.js에는 `node:test` 모듈과 `node --test` 실행기가 들어 있습니다. 린터는 선언하지 않은 변수처럼 오류 가능성이 있는 코드를 규칙으로 찾습니다. 포매터는 코드 의미를 바꾸려는 도구가 아니라 표현 형식을 일관되게 맞춥니다. TypeScript 프로젝트라면 `tsc --noEmit`을 추가해 파일을 만들지 않고 타입만 검사할 수 있습니다.
각 도구를 직접 외우기보다 `npm run test`, `npm run lint`, `npm run format:check`처럼 프로젝트 명령으로 고정합니다. `check` 스크립트는 이들을 순서대로 묶어 하나라도 실패하면 성공으로 끝나지 않게 합니다. 개발자 컴퓨터와 지속적 통합 환경이 같은 `npm run check`를 쓰면 검사 차이를 줄일 수 있습니다. 지속적 통합은 변경할 때마다 빌드와 검사를 자동 실행하는 방식입니다.
검사 도구는 프로젝트의 `devDependencies`에 기록하고 잠금 파일도 함께 관리해야 팀이 같은 버전을 설치하기 쉽습니다. 포맷 수정 명령과 확인 명령을 분리합니다. `format`은 파일을 바꾸고 `format:check`는 바꾸지 않은 채 차이만 알려 주므로 자동 검사에는 후자가 알맞습니다.
[따라하기]
빈 폴더에서 macOS·Linux 터미널이나 Windows PowerShell로 다음을 실행합니다. 명령은 세 운영체제에서 같습니다.
```sh
mkdir quality-demo
cd quality-demo
npm init -y
npm pkg set type=module
npm install --save-dev eslint @eslint/js prettier
npm pkg set scripts.test="node --test"
npm pkg set scripts.lint="eslint ."
npm pkg set scripts.format="prettier --write ."
npm pkg set scripts.format:check="prettier --check ."
npm pkg set scripts.check="npm run test && npm run lint && npm run format:check"
```
math.js를 만듭니다.
```javascript
export function add(a, b) {
return a + b;
}
```
math.test.js를 만듭니다.
```javascript
import assert from "node:assert/strict";
import test from "node:test";
import { add } from "./math.js";
test("두 수를 더한다", () => {
assert.equal(add(2, 3), 5);
});
```
eslint.config.js를 만듭니다.
```javascript
import js from "@eslint/js";
export default [js.configs.recommended];
```
`npm run check`를 실행합니다. 버전에 따라 전체 출력 모양은 달라도 테스트의 통과 수가 1이고, 린트 오류가 없으며, 포맷 검사에 모든 대상 파일이 형식에 맞는다는 결과가 나오면 성공입니다. `math.js`의 세미콜론을 지운 뒤 `npm run format:check`로 실패를 확인하고 `npm run format`으로 고친 다음 다시 검사합니다.
[흔한 실수]
포맷 검사 통과를 동작 검증으로 오해하거나 테스트 하나만 통과하면 전체가 안전하다고 생각하면 안 됩니다. 전역 설치된 도구에 의존하면 컴퓨터마다 버전이 달라질 수 있습니다. 자동 수정 뒤에는 반드시 변경 내용을 검토하고 테스트를 다시 실행합니다.
[보안 주의]
설치 전에 패키지 이름과 출처를 확인하고 잠금 파일의 예상하지 못한 변경을 살핍니다. 검사 로그나 테스트 데이터에 토큰·개인정보를 넣지 않습니다. 린트와 테스트는 보안 검토를 완전히 대신하지 못합니다. 실습은 본인 소유의 로컬 또는 허가된 격리 환경에서 수행합니다.
[직접 해볼 과제]
`subtract(a, b)` 함수와 정상·음수 결과 테스트를 하나씩 추가하세요. 일부러 기대값 하나를 틀리게 해 `npm run check`가 중단되는지 확인한 뒤 올바르게 고칩니다.
[확인문제]
1. 테스트, 린트, 포맷 검사는 각각 무엇을 확인하나요?
2. 자동 검사에서 `format`보다 `format:check`가 알맞은 이유는 무엇인가요?
3. 도구를 devDependencies에 기록하는 이유는 무엇인가요?
[다음 학습]
다음 과정 WEB-010에서는 웹 성능과 Core Web Vitals를 측정하고 개선합니다. JSTS-011에서는 JavaScript 입력 검증과 보안을 다룹니다.
[공식 참고 자료]
- Node.js 테스트 실행기: https://nodejs.org/api/test.html
- npm scripts 공식 문서: https://docs.npmjs.com/cli/v11/using-npm/scripts
- ESLint 시작 안내: https://eslint.org/docs/latest/use/getting-started
- ESLint 설정 파일: https://eslint.org/docs/latest/use/configure/configuration-files
- Prettier CLI 공식 문서: https://prettier.io/docs/cli
- TypeScript 컴파일러 옵션: https://www.typescriptlang.org/docs/handbook/compiler-options.html
- 이전글[WEB-010][실무] 웹페이지 로딩·반응·흔들림 측정하기 26.09.04
- 다음글[PY-010][실무] async와 await로 기다림 겹쳐 처리하기 26.09.04
댓글목록
등록된 댓글이 없습니다.
