지난 주 개발팀 미팅에서 프론트 테스트 코드에 대한 코드 리뷰 시간을 갖게 되었다. 사실상 현재 서비스에 짜여진 코드에 테스트 코드를 처음 도입하고 있는 시점이고, 백엔드도 최대한 빨리 테스트 코드를 짜야한다는 내용을 전달받은 적이 있다.

코드리뷰를 진행하면서 어려웠던 부분들과 코드리뷰를 보면서 개인적으로 느낀 점들을 공유하는 시간을 갖게 되었다. 나는 기능구현도 중요하지만 현재 서비스가 확장하고 고도화되는 시점에서 테스트코드를 짜는 것이 무지 번거로울 일이겠지만 멀리 보면 필요하다는 생각이 들었다.

이런저런 내용을 공유하면서 테스트코드, 테스트 커버리지, 코드 커버리지까지 이야기를 하게 되었다.

혼자 JS/ Node로 tdd 작성을 해본 경험은 있지만 사실상 실무에서 해본 경험은 없기 때문에 더 넓은 시야로 테스트 코드를 작성할 때 유의해야할 점(?)들을 알게 되었다.

우선, 테스트코드를 작성하기 전 코드 커버리지의 범위 및 기준을 정해야 한다.

그렇다면..

테스트 커버리지와 코드 커버리지는 뭘까?

  1. 테스트 커버리지
  • 시스템 및 소프트웨어에 대해 충분히 테스트가 되었는지 나타내는 정도
  • 수행한 테스트가 얼마나 테스트 대상을 커버했는지 나타낸다.
  1. 코드 커버리지
  • 테스트에 의해 실행된 소스 코드의 양을 나타낸 것 (즉, 이 테스트로 코드가 얼마나 covered 되었는지 나타내는 것)
  • 소스 코드를 기반으로 수행하는 화이트 박스 테스트를 통해 측정됨
  • 퍼센트(%) 단위로 표시되는데 커버리지가 100%라고 해서 완전히 버그 없는 소프트웨어라고 보장할 수는 없다.

💡 필요성

  • 테스트 코드는 발생할 수 있는 모든 시나리오에 대해 작성이 되어야 하는데, 이 때 코드 커버리지는 테스트를 수치화해 놓친 코드를 보완할 수 있게 해준다.

코드 커버리지의 기준은 여러가지 유형이 있는데 다음과 같다.

코드 커버리지 기준

구문 커버리지 (Statement Coverage)

결정 커버리지 (Dicision coverage)

조건 커버리지 (Condition Coverage)

profile
Soogineer's Devlog

0개의 댓글

Powered by GraphCDN, the GraphQL CDN