[단위 테스트] 좋은 테스트와 좋지 않은 테스트를 가르는 요인

단위 테스트가 프로젝트 성장에 도움이 되는 것은 맞지만, 테스트를 작성하는 것만으로는 충분하지 않다.

잘못 작성한 테스트는 여전히 같은 결과를 낳는다.

 

 

테스트가 좋은지 나쁜지에 따른 프로젝트 간 성장 추이의 차이

 

잘못 작성한 테스트도 초반에 코드가 나빠지는 것을 늦출 수 있다.

즉, 테스트가 전혀 없는 상황에 비해 개발 속도가 덜 느려진다.

프로젝트가 침체 단계에 진입하는 데 시간이 더 걸릴 수 있지만, 피할 수 는 없다.

 

모든 테스트가 똑같이 작성되지는 않는다.

일부 테스트는 아주 중요하고 소프트웨어 품질에 매우 많은 기여를 한다.

그 밖에 다른 테스트는 그렇지 않다.

잘못된 경고가 발생하고, 회귀 오류를 알아내는 데 도움이 되지 않으며, 유지 보수가 어렵고 느리다.

프로젝트에 도움이 되는지 여부를 명확하게 파악하지 않고 단위 테스트를 작성하는 데만 빠져들기 쉽다.

 

테스트의 가치와 유지 비용을 모두 고려해야한다.

• 기반 코드를 리팩토링할 때 테스트도 리팩토링하라.
• 각 코드 변경 시 테스트를 실행하라.
• 테스트가 잘못된 경고를 발생시킬 경우 처리하라.
• 기반 코드가 어떻게 동작하는지 이해하려고 할 때는 테스트를 읽는 데 시간을 투자 하라.

 

테스트는 자산이 아니라 책임이다

사람들은 종종 테스트가 많으면 많을수록 좋다고 생각한다.

그렇지 않다. 코드는 자산이 아니라 책임이다.

코드가 더 많아질수록, 소프트웨어 내의 잠재적인 버그에 노출되는 표면적이 더 넓어지고 프로젝트 유지비가 증가한다.

따라서 가능한 적은 코드로 문제를 해결하는 것이 좋다.

 

---

개인적 의견

 

기반 코드가 어떻게 동작하는지 이해하려고 할 때는 테스트를 읽는 데 시간을 투자 하라.

코드는 자산이 아니라 책임이다.

 

이 두 문구가 맘에 든다.

 

잘 작성된 테스트를 읽다보면 실제 프로덕션 코드를 읽지 않아도 도메인에 대한 이해도를 높힐 수 있다.

테스트는 시나리오 기반으로 작성되는 경우가 많다.

"A라는 상황이 주어졌을때, B라는 행동을 하고 B에 대한 행동을 검증한다"

이런 시나리오로 적힌 테스트를 읽다보면 프로덕션 코드를 읽는 것 보다 빠르게 이해도를 높힐 수 있다.

 

"코드는 자산이 아니라 책임이다" 라는 말도 공감한다.

테스트 코드가 많아지면 결국엔 리팩토링 할때 보다 쉽게 리팩토링 할 수 있게 만들어주지만

수 많은 테스트 코드 또한 리팩토링 대상이다.

똑같이 컴파일 오류가 발생한다.

버그를 찾는 시간보다는 적게 걸리지만, 컴파일 오류를 수정하는 것 또한 만만치 않은 시간이 걸린다.

---

 

참고

단위 테스트 (블라디미르 코리코프 지음)

https://seungo.tistory.com/26