1장, 단위 테스트의 목표
잘못된 내용이 있으면 댓글을 달아주세요.
단위 테스트의 목표
단위 테스트의 목표는 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것이다.
단위 테스트를 하지 않는다면, 처음에는 빨리 시작할 수 있다는 장점이 있지만 아래와 같은 문제점이 발생한다.
- 소프트웨어가 점점 고도화되면서 무언가를 변경할때마다 무질서도(엔트로피)가 증가한다.
- 버그를 만나 버그를 수정한다고 해도 이는 또 다른 버그를 양산할 수 있다.
- 한 부분을 수정할 때에 다른 부분이 망가질 수 있다.
테스트를 진행하면 위와 같은 문제점을 다소 해결할 수 있다. 테스트는 새로운 기능을 도입하거나 새로운 요구사항에 더 잘 맞게 리팩터링한 후에도 _기존 기능이 잘 작동하는지 확인_하는 데 도움을 주기 때문이다. 다만, 테스트 코드의 작성에는 초기 작업시간이 들어가고 계속해서 비용이 발생한다는 단점이 존재한다. 그럼에도 테스트 코드를 통해 지속성과 확장성을 얻어낼 수 있다.
- 예를 들면, 어떠한 기능을 추가 했을 때에 기존 코드의 테스트가 무결하다면 기존 코드의 신뢰성을 보장받을 수 있을 것이다.
좋은 테스트와 좋지 않은 테스트를 가르는 요인
일부 테스트는 소프트웨어의 품질에 많은 기여를 하지만 때로는 의미 없이 반복적으로 테스트 코드를 작성하는 데에만 빠져들 수 있으며 좋지 않은 테스트는 테스트를 하지 않는 것과 동일한 결과를 낳는다. 또한, 테스트 코드를 작성할 때에 분명히 비용이 들어감을 항상 견지해야 한다.
-
그래서 우리는, _고품질 테스트에 집중_해야 한다.
-
의미 없는 테스트 코드의 반복작성은 결코 좋지 않다.
비용만 늘어날 뿐이고, 테스트 코드도 코드다.
커버리지 지표
커버리지 지표는 테스트 스윝트가 소스 코드를 얼마나 실행하는 지를 백분율로 나타낸다.
코드 커버리지 = 테스트코드 실행 코드 라인 수 / 전체 라인 수
이러한 정의를 들었을 때, 커버리지가 높다면 좋아 보이지만 단순히 커버리지를 통해 좋은 테스트를 이루었다고 확인할 수 없다.
-
커버리지 지표가 낮다면,
이는 절대적인 테스트가 적다는 의미에서 좋은 지표지만
-
커버리지 지표가 높다고 하더라도
모든 테스트가 좋은 테스트이고 이를 통해 품질을 향상시키는 것을 보장하지 않는다.
또, 외부 라이브러리의 테스트를 확인할 수 없고 기존 코드 라인이 줄어든다면 커버리지가 높아지기에 품질을 보장하는 지표가 될 수 없다.
결론적으로 단순히 커버리지 지표를 높이는 것이 좋은 테스트를 보장하지 않는다.
성공적인 테스트 스위트 만들기
그러면 제대로 된 테스트는 어떻게 해야 하는 것일까?
또, 우리가 좋은 테스트를 했다고 어떠한 방법으로 확인할 수 있을까?
-
개발주기에 통합되어 있다.
끊임없이, 개발할때마다 테스트를 작성하고 실행한다.
-
코드베이스에서 가장 중요한 부분만을 대상으로 한다.
코드베이스의 모든 부분에 집중하기 보다는, 시스템의 가장 중요한 부분에 노력을 기울인다.
다른 부분은 간략하게 또는 간접적으로 검증하는 것이 좋다. 일반적으로
비즈니스 로직부분은 필히 테스트를 작성하는 것이 좋다. -
최소 유지비로 최대 가치
결국은 좋은 코드를 짜고, 좋은 품질의 테스트 코드를 작성하는 것이 중요하다.
이를 위해서 좋은 테스트는 무엇인가를 식별하는 능력을 기를 필요도 있다.
요약
- 단위 테스트의 목표는 소프트웨어 프로젝트의 지속 가능한 성장이다.
- 단위 테스트를 진행하지 않으면 아래의 문제점을 만날 수 있다.
- 소프트웨어가 점점 고도화되면서 무언가를 변경할때마다 무질서도(엔트로피)가 증가한다.
- 버그를 만나 버그를 수정한다고 해도 이는 또 다른 버그를 양산할 수 있다.
- 한 부분을 수정할 때에 다른 부분이 망가질 수 있다.
- 그럼에도, 저품질의 테스트코드 -예를 들어 의미없는 테스트-는 테스트의 복잡도만 높이기 때문에 좋지 않다.
- 이러한 의미에서, 커버리지 지표를 높이는 것 자체 또한 좋은 테스트를 보장하지 않는다.
- 성공적인 테스트를 만들기 위해서는, 다음 방법을 고민하자.
- 개발 주기에 통합
- 코드 베이스에서 중요한 부분만을 대상으로 진행
- 좋은 코드를 짜는 것이 가장 중요