원문: https://meticulous.ai/blog/frontend-unit-testing-best-practices/
이 가이드에서는 프런트엔드 단위 테스트에 대한 몇 가지 일반적인 모범 사례를 제시합니다. 먼저 각 권장 사항의 이점과 근거를 간략하게 설명한 다음, 테스트 사례들을 개선하기 위해 각 원칙을 실제로 어떻게 적용할 수 있는지에 대한 예시를 살펴보겠습니다.
아래 예제에서는 자바스크립트 및 Jest 테스트 프레임워크를 사용하지만 논의된 원칙은 모든 언어에 광범위하게 적용할 수 있습니다. 하지만 이런 사례들은 규칙이 아닌 모범 사례이므로 예외적인 것들을 염두 해 놓는 것이 중요하다 생각합니다.
1. 테스트에 린트 규칙 사용하기
eslint에서 제공하는 것과 같은 린트 또는 스타일 지정 규칙은 일반적으로 대부분의 최신 프런트엔드 코드 기반에서 표준으로 사용됩니다. 린트는 테스트 코드에서 실행 될 수 없는 코드가 있는 경우, 테스트를 실패로 이어지게 하는 코드들을 IDE에서 자동으로 찾아주는데 도움을 줍니다.
테스트 프레임워크에 사용할 수 있는 린트 규칙과 더 일반적인 테스트 실수를 방지하는 데 도움이 되는 방법을 고려하는 것이 좋습니다.
이유
- 린트는 일반적인 실수를 자동으로 강조 표시하고 수정 사항을 제안할 수 있습니다.
- 코드 기반 전체와 많은 기여자 간에 일관성을 보장합니다.
- 대부분의 최신 IDE와의 통합은 컴파일 시간 전에 작성되는 린트 오류를 추적하고 수정하는 데 도움이 될 수 있습니다.
- Husky와 같은 도구를 사용하여 pre-commit 훅의 일부로 린트 검사를 자동으로 실행할 수 있습니다. 모든 테스트 코드가 버전 관리에 저장되기 전에 린트 규칙을 통과하는지 확인합니다.
테스트할 예제 코드
// Promise를 사용한 비동기 GET 요청의 예시
function asyncRequest() {
return fetch("some.api.com")
.then(resp => resp.json())
.catch(() => {
throw new Error("Failed to fetch from some.api.com");
})
}잘못된 테스트 예시
// 잘못된 예시 - jest/valid-expect-in-promise 린트 오류 발생
// 비동기 함수가 resolve 되지 않으면 expect 함수도 resolve 되지 않습니다.
it("should resolve a successful fetch - bad", () => {
asyncRequest().then((data) => {
expect(data).toEqual({ id: 123 });
});
});
// 잘못된 예시 - jest/no-conditional-expect 린트 오류 발생
// 비동기 함수가 오류를 발생시키지 않으면 실행되지 않습니다.
it("should catch fetch errors - bad", async () => {
try {
await asyncRequest();
} catch (e) {
expect(e).toEqual(new Error("Failed to fetch from some.api.com"));
}
});더 나은 테스트 예시
// 더 나은 예시 - 린트 오류 없음
// promise가 resolve된 이후, expect 함수가 호출되는 것을 보장하기 위해 async와 await을 사용
it('should resolve fetch - better', async () => {
const result = await asyncRequest();
expect(result).toBeDefined();
})
// 더 나은 예시 - 린트 오류 없음
// expect 함수가 항상 호출되는 것을 보장하기 위해 async await을 사용
it("should catch fetch errors - better", async () => {
await expect(asyncRequest()).rejects.toThrow(
new Error("Failed to fetch from some.api.com")
);
});추가 참고 사항
Jest로 테스트를 작성하기 위한 몇 가지 권장되는 기본 린트 규칙
인기 있는 프런트엔드 JS 테스트 라이브러리에 대한 다른 린트 규칙을 추가하는 것을 고려하세요.
create-react-app을 사용하여 생성된 일반적인 JS/리액트 프로젝트에 eslint 규칙을 설정하는 방법
- package.json에 아래의
eslintConfig섹션을 추가합니다. - 그러면 모든
.jsx와.tsx파일에 대해 권장되는 eslint 규칙이 실행됩니다.
"eslintConfig": {
"extends": [
"react-app",
"react-app/jest",
"eslint:recommended"
],
"overrides": [
{
"files": ["**/*.js?(x)", "**/*.ts?(x)"],
"plugins": ["jest"],
"extends": ["plugin:jest/recommended"]
}
]
},2. DRY 원칙을 지키세요
beforeEach/afterEach를 사용해서 여러 테스트에서 반복되는 코드 블록과 유틸리티 기능에 대한 로직을 캡슐화합니다.
이유
- 공유되는 로직이 한 곳에 있으면 쉽게 포함하고 업데이트할 수 있습니다.
beforeEach/afterEach코드 블록 내에서 자동으로 호출되는 경우, 일반적인 설정/해제(setup/teardown) 논리를 잊어버릴 가능성이 적습니다.- 반복을 줄이면 테스트를 더 짧고 읽기 쉽게 만들 수 있습니다.
테스트할 예제 코드
// booking 객체를 검증하는 함수의 예시
function validateBooking(booking) {
const validationMessages = [];
if (booking.startDate >= booking.endDate) {
validationMessages.push(
"Error - Booking end date should be after the start date"
);
}
if (!booking.guests) {
validationMessages.push(
"Error - Booking must have at least one guest"
);
}
return validationMessages;
}잘못된 테스트 예시
// 잘못된 예시 - 유사한 booking 객체에 대한 반복적인 초기화
describe("ValidateBooking - Bad", () => {
it("should return an error if the start and end date are the same", () => {
const mockBooking = {
id: "12345",
userId: "67890",
locationId: "ABCDE",
guests: 2,
startDate: new Date(2022, 10, 10),
endDate: new Date(2022, 10, 10),
};
expect(validateBooking(mockBooking)).toEqual([
"Error - Booking end date should be after the start date",
]);
});
it("should return an error if there are fewer than one guests", () => {
const mockBooking = {
id: "12345",
userId: "67890",
locationId: "ABCDE",
guests: 0,
startDate: new Date(2022, 10, 10),
endDate: new Date(2022, 10, 12),
};
expect(validateBooking(mockBooking)).toEqual([
"Error - Booking must have at least one guest",
]);
});
it("should return no errors if the booking is valid", () => {
const mockBooking = {
id: "12345",
userId: "67890",
locationId: "ABCDE",
guests: 2,
startDate: new Date(2022, 10, 10),
endDate: new Date(2022, 10, 12),
};
expect(validateBooking(mockBooking)).toEqual([]);
});
});더 나은 테스트 예시
// 더 나은 예시
// 재사용 가능한 createMockValidBooking이라는 팩토리 함수에 중복된 booking 객체 생성이 위임되었습니다.
describe("ValidateBooking - Better", () => {
function createMockValidBooking() {
return {
id: "12345",
userId: "67890",
locationId: "ABCDE",
guests: 2,
startDate: new Date(2022, 10, 10),
endDate: new Date(2022, 10, 12),
};
}
it("should return an error if the start and end dates are the same", () => {
const mockBooking = {
...createMockValidBooking(),
startDate: new Date(2022, 10, 10),
endDate: new Date(2022, 10, 10),
};
expect(validateBooking(mockBooking)).toEqual([
"Error - Booking end date should be after the start date",
]);
});
it("should return an error if there are fewer than one guests", () => {
const mockBooking = {
...createMockValidBooking(),
guests: 0,
};
expect(validateBooking(mockBooking)).toEqual([
"Error - Booking must have at least one guest",
]);
});
it("should return no errors if the booking is valid", () => {
const mockBooking = createMockValidBooking();
expect(validateBooking(mockBooking)).toEqual([]);
});
});3. describe 블록에서 관련 테스트를 그룹화하기
이유
- 제목이 좋은
describe블록은 관련 테스트를 그룹으로 분리하여 테스트 파일을 구성하는 데 도움이 됩니다. - 단일
describe블록의 경우,beforeEach/afterEach를 추가하여 테스트의 하위 집합에 특정한 설정/해제(setup/teardown) 로직을 캡슐화하기 더 쉽습니다. (위의 "DRY 원칙을 지키세요" 규칙 참조) - 내부
describe블록은 외부describe블록에서 설정 로직을 확장할 수 있습니다.
테스트할 예제 코드
// 단순화된 스택 데이터 구조 클래스의 예시
class Stack {
constructor() {
this._items = [];
}
push(item) {
this._items.push(item);
}
pop() {
if(this.isEmpty()) {
throw new Error("Error - Cannot pop from an empty stack");
}
return this._items.pop();
}
peek() {
if(this.isEmpty()) {
throw new Error("Error - Cannot peek an empty stack");
}
return this._items[this._items.length-1];
}
isEmpty() {
return this._items.length === 0;
}
}잘못된 테스트 예시
// 잘못된 예시 - 테스트를 그룹화하는 데 사용되는 내부 "describe" 블록이 없습니다.
// 각 테스트 제목의 "on a non-empty stack" 또는 "on an empty stack"의 반복 사용에 대해 유의하세요
describe("Stack - Bad", () => {
it("should return isEmpty as true if the stack is empty", () => {
const stack = new Stack();
expect(stack.isEmpty()).toBe(true);
});
it("should return isEmpty as false if the stack is non-empty", () => {
const stack = new Stack();
stack.push(123);
expect(stack.isEmpty()).toBe(false);
});
it("should throw error when peeking on an empty stack", () => {
const stack = new Stack();
expect(() => stack.peek()).toThrowError(
"Error - Cannot peek an empty stack"
);
});
it("should return the top item when peeking a non-empty stack", () => {
const stack = new Stack();
stack.push(123);
expect(stack.peek()).toEqual(123);
});
it("should throw an error when popping from an empty stack", () => {
const stack = new Stack();
expect(() => stack.pop()).toThrowError(
"Error - Cannot pop from an empty stack"
);
});
it("should return the top item when popping a non-empty stack", () => {
const stack = new Stack();
stack.push(123);
expect(stack.pop()).toEqual(123);
});
});더 나은 테스트 예시
// 더 나은 예시 - 내부 "describe" 블록을 사용하여 관련 테스트를 그룹화합니다.
// 또한 beforeEach를 사용하여 각 테스트 내에서 반복적인 초기화를 줄입니다.
describe("Stack - Better", () => {
let stack;
beforeEach(() => {
stack = new Stack();
});
describe("empty stack", () => {
it("should return isEmpty as true", () => {
expect(stack.isEmpty()).toBe(true);
});
it("should throw error when peeking", () => {
expect(() => stack.peek()).toThrowError(
"Error - Cannot peek an empty stack"
);
});
it("should throw an error when popping", () => {
expect(() => stack.pop()).toThrowError(
"Error - Cannot pop from an empty stack"
);
});
});
describe("non-empty stack", () => {
beforeEach(() => {
stack.push(123);
});
it("should return isEmpty as false", () => {
expect(stack.isEmpty()).toBe(false);
});
it("should return the top item when peeking", () => {
expect(stack.peek()).toEqual(123);
});
it("should return the top item when popping", () => {
expect(stack.pop()).toEqual(123);
});
});
});4. 단위 테스트는 실패할 이유가 하나만 있어야 합니다.
이유
- 이름에서 알 수 있듯이 단위 테스트는 코드의 단일 "단위"만 테스트해야 합니다.
- 하나의 실패 이유만 있는 경우, 테스트 실패의 근본 원인을 식별하는 데 소요되는 시간이 줄어듭니다.
- SOLID 사례의 단일 책임 원칙을 따릅니다.
- 더 짧고 읽기 쉬운 단위 테스트를 권장합니다.
테스트할 예제 코드
위에서 설명한 Stack 클래스가 이 섹션의 예제로 사용됩니다.
잘못된 테스트 예시
// 잘못된 예시
// 단일 테스트에서 "pop" 함수에 대한 두 개의 개별적인 논리 분기를 확인하고 있습니다.
// 두 가지 expect 함수에서 "stack.pop()"을 두 번 호출합니다.
describe("Stack - Bad", () => {
let stack;
beforeEach(() => {
stack = new Stack();
});
it("should only allow popping when the stack is non-empty", () => {
expect(() => stack.pop()).toThrowError();
stack.push(123);
expect(stack.pop()).toEqual(123);
});
});더 나은 테스트 예시
// 더 나은 예시
// 각 테스트는 "pop" 함수에 대해 하나의 논리적 분기를 거칩니다.
// 테스트당 하나의 "stack.pop()"를 호출하고 하나의 "expect"를 호출합니다.
describe("Stack - Better", () => {
let stack;
beforeEach(() => {
stack = new Stack();
});
it("should throw an error when popping from an empty stack", () => {
expect(() => stack.pop()).toThrowError();
});
it("should return the top item when popping a non-empty stack", () => {
stack.push(123);
expect(stack.pop()).toEqual(123);
});
});5. 테스트를 독립적으로 유지하기
이유
- 한 테스트의 결과는 다른 테스트에 영향을 미치지 않아야 합니다.
- 테스트 간에 상태 또는 mock 인스턴스를 공유하면 잘못 통과하는 취약하거나 "깨지기 쉬운(flaky)" 테스트로 이어질 수 있습니다.
- 새 테스트가 추가되거나 테스트 순서가 변경되면 종속 테스트가 예기치 않게 실패할 수 있습니다.
테스트할 예제 코드
// 콜백 함수를 받고 설정한 밀리초 후에 콜백 함수를 실행하는 함수에 대한 간단한 예시
function callInFive(callback) {
setTimeout(callback, 5000);
}잘못된 테스트 예시
// 잘못된 예시 - 아래 테스트는 독립적이지 않습니다.
// mockCallback 함수는 테스트 사이에 재설정되지 않습니다.
// 한 테스트의 타이머는 다음 테스트를 시작하기 전에 지워지지 않습니다.
describe("callInFive - Bad", () => {
beforeEach(() => {
// jest 라이브러리를 사용하여 각 테스트 내 시간 경과를 제어
jest.useFakeTimers();
})
const mockCallback = jest.fn();
it("should not call callback before five seconds elapse", () => {
callInFive(mockCallback);
jest.advanceTimersByTime(5000 - 1);
expect(mockCallback).not.toHaveBeenCalled();
});
it("should call callback after five seconds elapse", () => {
callInFive(mockCallback);
jest.advanceTimersByTime(5000);
expect(mockCallback).toHaveBeenCalled();
});
});더 나은 테스트 예시
// 더 나은 예시
// 테스트 간에 모킹하는 함수와 진행 중인 타이머를 재설정합니다.
describe("callInFive - Better", () => {
beforeEach(() => {
jest.useFakeTimers();
// 각 테스트를 시작하기 전에 모든 모킹 및 스파이를 재설정하는 것을 잊지마세요.
jest.resetAllMocks();
})
// 남아있는 타이머를 모두 제거하고, 실제 시간 기능이 제대로 동작하도록 복원하는 것을 잊지 마세요.
afterEach(() => {
jest.runOnlyPendingTimers();
jest.useRealTimers();
})
const mockCallback = jest.fn();
it("should not call callback before five seconds elapse", () => {
callInFive(mockCallback);
jest.advanceTimersByTime(5000 - 1);
expect(mockCallback).not.toHaveBeenCalled();
});
it("should call callback after five seconds elapse", () => {
callInFive(mockCallback);
jest.advanceTimersByTime(5000);
expect(mockCallback).toHaveBeenCalled();
});
});추가 참고 사항
- jest 구성 파일에
resetMocks: true를 추가하거나package.json에 다음을 추가하여 각 테스트 전에 자동으로 모킹을 재설정하도록 Jest 테스팅 라이브러리를 구성할 수 있습니다.
"jest": {
"resetMocks": true
}- create-react-app으로 리액트 프로젝트를 시작하면 내장된 jest 구성에
resetMocks: true가 자동으로 추가됩니다. (문서 참조) 이는 각 테스트 전에 자동으로 jest.resetAllMocks()를 호출하는 것과 같습니다. - 테스트가 무작위 순서로 실행되도록 하면 단위 테스트가 독립적이지 않은 경우를 식별하는 데 도움이 될 수 있습니다.
6. 다양하게 입력되는 매개변수 테스트하기
이유
- 이상적으로 테스트는 테스트 중인 코드를 통해 가능한 모든 코드 경로를 확인해야 합니다.
- 우리는 배포된 코드가 사용자가 입력할 수 있는 모든 입력을 처리할 수 있다고 확신하고 싶습니다.
- 우리는 올바른 것으로 알고 있는 코드 경로를 트리거하는 입력을 사용하여 테스트하는 쪽으로 편향될 수 있습니다. 입력 범위를 테스트하면 우리가 고려하지 않았을 수도 있는 엣지 케이스를 확인하는 데 도움이 될 수 있습니다.
테스트할 예제 코드
// 특정 길이의 배열을 생성하고 주어진 값으로 채우는 함수의 예시
function initArray(length, value) {
// 이 if 조건에 오류가 있음을 유의하세요.
// 길이가 0이면 오류가 발생합니다.
if (!length) {
throw new Error(
"Invalid parameter length - must be a number greater or equal to 0"
);
}
return new Array(length).fill().map(() => value);
}잘못된 테스트 예시
// 잘못된 예시 - 아래의 테스트는 모두 통과하고, 이는 마치 이 테스트들이 모든 코드 경로를 고려한 것처럼 보일 수 있습니다.
// 하지만 JS에서 0은 falsy임을 유의하세요.
// 아래 테스트는 길이가 0 또는 -1인 배열을 생성하려는 경우를 확인하지 않습니다.
describe("initArray - Bad", () => {
it("should create an array of given size filled with the same value", () => {
expect(initArray(3, { id: 123 })).toEqual([
{ id: 123 },
{ id: 123 },
{ id: 123 },
]);
});
it("should throw an error if the array length parameter is invalid", () => {
expect(() => initArray(undefined, { id: 123 })).toThrowError();
});
});더 나은 테스트 예시
// 더 나은 예시 - 배열을 생성할 때, 길이가 0 또는 -1이라는 엣지 케이스에 대한 테스트를 추가했습니다.
describe("initArray - Better", () => {
it("should create an array of given size filled with the same value", () => {
expect(initArray(3, { id: 123 })).toEqual([
{ id: 123 },
{ id: 123 },
{ id: 123 },
]);
});
it("should handle an array length parameter of 0", () => {
expect(initArray(0, { id: 123 })).toEqual([]);
});
it("should throw an error if the array length parameter is -1", () => {
expect(() => initArray(-1, { id: 123 })).toThrowError();
});
it("should throw an error if the array length parameter is invalid", () => {
expect(() => initArray(undefined, { id: 123 })).toThrowError();
});
});추가 참고 사항
또한 fast-check와 같은 테스트 프레임워크를 사용하여 처리되지 않은 입력으로 실수를 잡을 수도 있습니다. 이것은 자동으로 코드 커버리지를 개선하고 버그를 찾을 가능성을 높일 수 있는 임의의 값 범위에 대해 기능을 테스트합니다.
// 더 나은 예시 - fast-check와 같은 프레임워크를 사용하여 입력 범위에 대한 테스트 케이스를 생성할 수 있습니다.
// 기본적으로 각 asset 메서드는 임의의 값으로 100번 실행됩니다.
describe("initArray - Better - Using fast-check", () => {
it("should return an array of specified length", () =>
fc.assert(
fc.property(
fc.integer({ min: 0, max: 100 }),
fc.anything(),
(length, value) => {
expect(initArray(length, value).length).toEqual(length);
}
)
));
it("should throw an error if initialising array of length < 0", () =>
fc.assert(
fc.property(
fc.integer({ max: -1 }),
fc.anything(),
(length, value) => {
expect(() => initArray(length, value)).toThrowError();
})
));
});결론
요약하자면, 이 블로그에서는 프런트엔드 테스트에서 다음과 같은 방법의 이점과 자바스크립트/Jest의 예제 테스트에 적용하는 방법을 설명했습니다.
- 테스트에 린트 규칙 사용하기
- DRY 원칙을 지키세요
- describe 블록에서 관련 테스트를 그룹화하기
- 단위 테스트는 실패할 이유가 하나만 있어야 합니다.
- 테스트를 독립적으로 유지하기
- 다양하게 입력되는 매개변수 테스트하기
이것들은 테스트를 작성할 때 고려해야 할 몇 가지 규칙에 불과하므로 프런트엔드 모범 사례에 대해 자세히 알아보려면 Meticulous 블로그의 Frontend Testing Pyramid와 자바스크립트 UI 테스트 모범 사례에서 찾을 수 있습니다.
읽어 주셔서 감사합니다!
저자 Alex Langdon
FrontEnd Developer
각 권장 사항의 이점과 근거를 간략하게 설명하고, 이러한 테스트 사례들을 개선하기 위해 각 원칙을 실제로 어떻게 적용할 수 있는지 자바스크립트 및 Jest 프레임워크를 사용한 예시도 함께 나와 있습니다. official dunkinrunsonyou.com