개발에서 “테스트”가 진짜로 편해지는 순간들

테스트를 왜 하냐고요? 결국 “변경” 때문에 합니다

개발은 만들고 끝이 아니라, 계속 바꾸는 일입니다.

• 요구사항이 바뀐다
• 성능 개선을 한다
• 리팩터링을 한다
• 라이브러리 버전을 올린다 이때 테스트가 없으면 변경은 늘 불안을 동반합니다. 반대로 테스트가 있으면, 변경 후에 “정상 동작”을 빠르게 확인할 수 있어요. 특히 팀 개발에서는 내가 고친 부분이 다른 기능을 망가뜨렸는지를 빨리 잡아주는 안전망 역할을 합니다.

가장 작은 단위로 시작하기: 단위 테스트 예시

테스트를 거창하게 시작할 필요는 없습니다. “문제가 자주 생기는 로직” 하나만 골라보세요. 예를 들어, 할인 금액 계산처럼 자주 수정되는 규칙은 테스트와 궁합이 좋습니다.

예시: 할인 금액 계산 함수 + 간단 테스트 (JavaScript)

// discount.js
export function calcPrice(original, rate) {
  if (original < 0) throw new Error("original must be >= 0");
  if (rate < 0 || rate > 1) throw new Error("rate must be between 0 and 1");
  return Math.round(original * (1 - rate));
}

// discount.test.js (Jest 스타일 예시)
import { calcPrice } from "./discount.js";

test("10% 할인 적용", () => {
  expect(calcPrice(10000, 0.1)).toBe(9000);
});

test("0원은 그대로", () => {
  expect(calcPrice(0, 0.2)).toBe(0);
});

test("잘못된 입력은 에러", () => {
  expect(() => calcPrice(-1, 0.1)).toThrow();
  expect(() => calcPrice(10000, 2)).toThrow();
});

여기서 핵심은 엣지 케이스입니다. 정상 케이스만 확인하면 실제 장애를 막기 어렵고, 이상한 입력에서 무너지는 경우가 많거든요.

“테스트가 쉬운 코드”는 따로 있습니다

테스트를 작성하다 보면 자연스럽게 코드 품질이 올라갑니다. 왜냐하면 테스트는 이런 코드를 좋아해요.

• 입력과 출력이 명확한 함수

• 외부 의존성(DB, 네트워크)이 분리된 구조

• 상태가 최소화된 설계 반대로 아래처럼 한 함수가 다 해버리면 테스트가 어려워집니다.

• 내부에서 바로 API 호출

• 랜덤값/시간에 의존

• 전역 상태를 마구 수정

작은 팁: 시간 의존 로직은 “주입”하면 편해집니다

예를 들어 “오늘 날짜 기준” 로직이 있다면, 함수 안에서 바로 Date.now()를 쓰기보다 값을 받아오게 만들면 테스트가 쉬워져요. 작은 구조 변경 하나로 테스트 난이도가 확 내려갑니다.

현실적인 운영 팁: 테스트는 “전부”가 아니라 “핵심”부터

테스트를 도입할 때 가장 흔한 실패는 처음부터 완벽하게 하려는 것입니다. 추천 흐름은 이렇습니다.

1. 장애가 났던 로직부터 테스트 추가
2. 자주 바뀌는 계산/정책/검증 로직 커버
3. 버그가 나오면 “재발 방지 테스트”를 하나씩 쌓기 이 방식은 속도가 느려 보이지만, 실제로는 팀 전체의 수정 비용을 확 줄여줍니다. 테스트는 한 번에 끝내는 프로젝트가 아니라 쌓이는 자산이니까요.

마무리: 테스트는 개발자의 “심리적 안정장치”입니다

테스트를 갖춘 프로젝트는 코드가 특별히 멋져 보이지 않아도, 수정이 편하고 배포가 덜 무섭습니다. 결국 개발에서 중요한 건 “한 번 잘 만드는 것”보다 계속 잘 바꿀 수 있는 것이더라고요.

다음에 시간을 내서, 지금 프로젝트에서 가장 자주 깨지는 함수 하나만 골라 테스트를 붙여보세요. 그 작은 시작이, 생각보다 큰 차이를 만들어줍니다.