B-3. 테스트 범위와 전략 — 뭘 테스트하고, 뭘 테스트하지 말아야 할까?
이렇게 읽어보세요: 선배 크루의 고민 → 토론 질문을 먼저 읽고 → AS-IS 코드를 직접 분석 → 리뷰어의 피드백으로 관점 확인 → 탐색 미션에서 PR 깊이 파기
선배 크루의 고민
“TDD가 오히려 사고를 경직시키는 느낌이 들었습니다. 테스트를 먼저 작성하다 보니 구현 방향이 테스트에 끌려가는 것 같아서, 어느 정도 수준으로 테스트를 작성해야 할지 감이 안 잡힙니다.” — 부엉이, PR #202
“리팩터링할 때마다 테스트도 같이 수정해야 해서 번거롭습니다. 구현 세부사항에 의존하는 테스트가 많은 것 같은데, 요구사항 기반으로 테스트를 작성하는 방법이 궁금합니다.” — 쿠마, PR #200
“테스트에서도 매직 넘버 대신 상수를 사용해야 하는지 궁금합니다. 테스트의 가독성을 위해 직접 값을 쓰는 게 나을 수도 있다고 생각했는데, 유지보수 관점에서는 상수가 나을 것 같기도 하고요.” — 기린, PR #356
이 코드를 보면서 이야기해봅시다
- “당첨 금액 상수가 바뀌면 이 테스트는 어떻게 되나요? 테스트가 ‘요구사항 변경’에 깨지는 것과 ‘버그’에 깨지는 것의 차이는 뭘까요?”
- “주석에 있는
price / PRIZE.fifth방식과2000000000방식, 각각의 장단점은?”
AS-IS 코드
// __tests__/Winning.test.js — 기대값을 하드코딩하여 테스트
test('전체 당첨 금액을 계산한다', () => {
// given
const winning = new Winning(winningNumbers, bonusNumber);
winning.calculateRankHistory(lottos);
// then - 하드코딩된 기대값: 요구사항 변경 시 테스트도 수정 필요
expect(winning.getTotalPrize()).toEqual(2000000000);
// 리뷰어 크리스의 제안: 계산식을 드러내는 방식으로 변경
// expect(winning.getTotalPrize()).toEqual(price / PRIZE.fifth);
});리뷰어의 피드백
“ㅋㅋㅋㅋㅋ 에러에 대한 테스트가 필요하다고 피드백 드렸더니 정말 성실하게 다 해주셨군요!! 좋습니다..! 그런데 성공하는 경우도 함께 있으면 더 좋겠네요 ㅋㅋㅋㅋ (죄송)” — PR #122 (링크 )
“현재의 계산식을 염두에 두고 직접 값을 입력해 테스트하는 방식은, 유효하지 않은 테스트는 아니지만 요구사항이 바뀜에 따라 해당 테스트 코드도 같이 바꿔줘야 할 가능성이 큽니다. 추후에 리소스를 소모할 가능성이 있는 테스트 코드는 최대한 지양하는 것이 좋습니다.” — PR #355 (링크 )
“각 테스트는 이전 테스트에 영향을 안받도록해야겠습니다. 상위컨텍스트에 공용으로 사용하는 데이터를 두기보단 테스트데이터를 생성하는 함수를 하나 만들어보는게 좋겠어요” — PR #202 (링크 )