1장 - 단위 테스트의 목표

Junuuu 2023. 6. 10. 00:01

테스트를 작성하는 노력은 줄이고, 그에 따르는 이득은 극대화해야 한다.

대부분의 프로그래머는 단위 테스트를 실천하고 중요성을 알고 있다.

그냥 쓰고 버리는 프로젝트가 아니면, 단위 테스트는 늘 적용해야 한다.

요새의 논쟁은 바뀌고 있다, 단위 테스트를 작성해야 하는가? -> 좋은 단위 테스트를 작성하는 것은 어떤 의미인가?

좋은 테스트와 좋지 않은 테스트의 차이는 취향이나 개인적인 선호도의 문제가 아닌 프로젝트의 성패를 가르는 문제다.

이 책은 테스트 작성 노력 대비 최대의 이익을 이끌어 내는 방법으로 안내한다.

흔히 단위 테스트 활동이 더 나은 설계로 이어진다고 한다.

하지만 이는 단위 테스트의 주목표는 아니다.

단위 테스트의 목표는 소프트웨어 프로젝트의 성장을 지속 가능하도록 하는 것이다.

테스트를 활용하면 새로운 기능을 도입하거나, 새로운 요구 사항에 더 잘 맞게 리팩터링 한 후에도 기존 기능이 잘 동작하는지 확인하는데 도움이 된다.

테스트 코드의 비용요소는 다음과 같다.

즉, 좋은 테스트와 나쁜 테스트를 구별하는 것이 중요하다.

일반적으로 테스트 커버리지 숫자가 높을수록 좋지만, 100% 커버리지라고 해서 반드시 양질의 테스트를 보장하지 않는다.

예를 들어 다음과 같은 코드는 쉽게 커버리지가 바뀌지만 테스트가 개선되지 않습니다.

if(input.Length > 5)
	return true;
return false;

예를들어 input이 3인 "abc"문자열을 주고 테스트한다면 true일 경우에는 테스트 커버리지에 포함되지 않습니다.

하지만 다음과 같이 코드를 리팩터링 하면 테스트 커버리지가 100%로 증가합니다.

return input.Length > 5;

고된 작업 이야기

테스트 커버리지를 100% 엄격히 오규하는 관리자가 담당하는 프로젝트에 참여한 경험이 있었습니다.

심지어 특정 툴을 통해 커버리지가 낮아지는 경우 빌드 시스템에서 거부하게 할 수 있습니다.

하지만 개발자들은 시스템을 속일 방법을 찾게 되었고, 생산적인 활동에서 벗어나게 되었습니다. (예를 들면, 검증 없는 테스트)

결국 요구사항은 90% -> 80% -> 결국엔 완전히 없어지게 되었습니다.

특정 커버리지 숫자를 목표로 하지 말자

커버리지 지표는 지표 그 자체로보고 목표로 여기지 말자.

병원에서 체온이 높으면 열이 난다는 것을 의미하지만 병원은 적절한 체온을 목표로 해서는 안된다.

적절한 단위 테스트는 이미 충분히 어렵고, 커버리지 숫자를 강요하면 개발자들은 테스트 대상에 신경 쓰지 못하고 목표를 달성하기 더 어려워집니다.

믿을 만한 방법은 각 테스트를 하나씩 따로 평가하는 것뿐입니다.

요점은 자동으로 확인할 수 없으며, 개인 판단에 맡겨야 합니다.

성공적인 테스트는 다음과 같은 특성을 갖고 있습니다.

개발 주기에 통합되어 있음
- 이상적으로는 코드가 변경될 때마다 아무리 작은 것이라도 실행해야 한다.
코드베이스에서 가장 중요한 부분만을 대상으로 한다.
- 대부분의 애플리케이션에서 가장 중요한 것은 비즈니스 로직이며, 비즈니스 로직 테스트가 시간 투자 대비 최고의 수익을 낼 수 있다.
- 일반적으로 인프라 레이어보다 도메인 모델에 관심이 더 많이 갖는 것이 옳다.
최소한의 유지비로 최대의 가치를 끌어낸다.
- 이를 위해서는 가치가 있는 테스트를 식별하고, 작성할 수 있어야 한다.

테스트를 분석하는 데 사용할 수 있는 기준틀을 설명합니다.

새로운 관점에서 많은 테스트를 볼 수 있으며, 어떤 것이 프로젝트에 기여하고 어떤 것을 리팩터링해야 하거나 완전히 제거해야 하는지 알 수 있습니다.

기초를 다진 후에는 기존 단위 테스트 기술과 실천을 다룹니다.