Unit Testing

단위 테스트에 시간을 투자할때는 항상 최대한 이득을 얻도록 노력해야 한다.

테스트에 드는 노력을 가능한 줄이고, 그에 따르는 이득을 최대화해야 한다.

단위 테스트의 목표

핵심은 소프트웨어의 지속 가능한 성장을 가능하게 하는 것

성장곡선

테스트 코드가 부재한 프로젝트는 시간이 지날수록 개발 속도가 현저히 낮아진다.

기능이 추가되거나 수정되었을 때 적절히 리팩토링을 통한 관리가 필요하지만 테스트 코드의 부재로 리팩토링을 시도하는 것조차 불안한 작업이 되어 기피하게 된다.

이런 것들이 계속 쌓이다 보면 코드베이스는 썩어들어가게 되며 유지보수가 불가능해 개발속도가 현저히 낮아지게 되는 것이다. 이러한 현상을 소프트웨어 엔트로피라고도 한다.

테스트 이런 현상을 방지할 수 있는 안전망 역할을 한다.

새로운 기능이 추가되거나 수정되었을 때 요구사항에 더 잘 맞게 리팩토링을 한 후에도 기존 기능이 잘 동작되는지 확인할 수 있어 지속 가능하며 확장 가능한 프로젝트를 만들어 나갈 수 있다.

단위 테스트와 코드설계

좋은 부정 지표, 좋지 않은 긍정 지표

단위 테스트는 저품질 코드를 가려내기 위한 좋은 부정 지표이지만 단위 테스트를 할 수 있다는 것이 반드시 좋은 코드를 의미하진 않는다.

테스트를 작성하기 어려운 저품질 코드는 아래와 같은 문제점들이 있다.

• 코드 간 결합도 및 의존성이 높다.

• SRP(단일책임원칙) 을 지키지 않아 하나의 코드에 여러 역할이 포함되어 있다

쉬운 테스트를 위해 리팩토링하는 과정에서 코드베이스는 최소한 저품질 코드에서 벗어나 더 나은 설계로 이어 질 수 있다.

좋은 테스트, 나쁜 테스트를 구별하자.

테스트를 작성하는게 능사가 아니다. 나쁜 테스트는 여전히 같은 결과를 낳는다.

모든 코드를 테스트 할 필요는 없다.

테스트 코드를 작성하는 것에만 매몰되어 영양가 없는 테스트에 시간을 버리게 되므로 프로젝트의 도움이 되는지 여부를 파악하는 것이 중요하다.

지속 가능한 프로젝트 성장을 위해서는 고품질의 테스트에만 집중해야 한다.

테스트 품질 측정을 위한 커버리지 지표

커버리지 지표는 테스트 스위트가 소스코드를 얼마나 실행하는지 백분율로 나타낸다.

커버리지 지표는 코드 커버리지, 분기 커버리지로 나뉜다.

커버리지 지표는 테스트 스위트의 품질을 평가하는데 사용되며 일반적으로 높을 수록 더 좋지만 높다고 좋은 테스트라는 것을 보장하지 못한다.

좋은 테스트 스위트의 품질을 결정하기에 커버리지 지표만으로는 충분하지 않다.

높은 커버리지 숫자를 목표로 두지 말고 좋은 부정 지표로서 사용하자.

코드 커버리지의 허점

코드 커버리지 = 제품 코드 라인 수 / 전체 라인 수

테스트 커버리지는 단순히 라인수의 백분율로 나타내기에 낮으면 테스트가 충분하지 않다는 좋은 증거이지만 높다고 해서 양질의 테스트라고 보지 못한다.

if문이 두줄에서 한줄로 줄었다고 해서 양질의 테스트라 볼 수 있는가?

분기 커버리지의 허점

분기 커버리지 = 통과 분기 / 전체 분기 수

분기 커버리지는 코드 커버리지 보다 더 정확한 결과를 제공한다.

코드베이스에서 분기하는 모든 구문을 합산하고 그 중 테스트가 실행하는 분기가 얼만지 측정하는 것

단순히 분기 개수만 다루기 때문에, 모든 가능한 결과를 검증한다고 보장할 수 없다.

의미가 있으려면 모든 측정 지표를 검증해야 한다.

그렇다면 성공적인 테스트 스위트는 어떻게 결정하는가?

성공적인 테스트 스위트의 특성

• 개발 주기에 통합됨

• 코드베이스에서 가장 중요한 부분만을 대상으로 함

• 최소한의 유지비로 최대의 가치를 끌어냄

개발 주기에 통합

자동화된 테스트를 하기 위해선 끊임없이 하는 것 뿐

코드가 변경될 때마다 테스트 실행하는 것을 의미한다.

최소한, 코드 리뷰를 요청하기 전,, main 브랜치에 머지하기 전, 사용자에게 배포되기 전에는 테스트 코드를 포함시키자.

코드베이스 내의 가장 중요한 부분만을 대상으로

시스템의 가장 중요한 부분에 단위 테스트를 몰두하고, 그 외는 갼략히 또는 간접적으로만 검증하자.

프로젝트 내에서 가장 중요한 부분이라 하면 비즈니스(도메인) 로직이다.

비즈니스 로직 테스트가 시간 투자 대비 최고의 효율을 낸다.

단위 테스트를 도메인 모델에만 집중하기 위해서는 도메인 모델을 코드 베이스 중 중요하지 않은 부분과 분리해야 한다.

최소 유지비로 최대 가치를

가장 핵심적이지만 가장 어렵다.

가치가 유지비를 상회하는 테스트만 스위트에 남기는게 좋다.

가치가 높은 테스트를 식별하기 위해서는 기준 틀이 필요하며 가치가 있는 테스트를 작성하는 방법도 알아야 한다.

가치 있는 테스트를 작성하기 위해서는 기반 코드를 잘 설계해야 한다.

즉, 기반 코드에 노력을 기울여야 가치 있는 테스트를 작성할 수 있게 된다.