테스트 커버리지에 대한 생각(SLASH 21 영상 참고)

본 포스팅은 토스 SLASH 21 - 테스트 커버리지 100%를 보고, 느낀점과 개인 프로젝트를 진행하면서 테스트 커버리지 80% 이상을 달성하면서 느낀점을 토대로 작성했습니다.

 

클린 코더라는 책에서는, 100% 테스트 커버리지를 권장한다고 적혀 있다.

테스트 커버리지 100%를 유지하려면, 모든 부분에 대한 테스트 코드를 작성해야하고, 테스트하기 어려운 부분이 존재함에도 테스트를 작성해야 하기 때문에, 작업에 어려움이 있을것 이라고 예상했다.

영상에서는 테스트 커버리지 84%를 달성한 시점을 기준으로, 커버리지가 기준을 달성하지 못하면 배포가 되지 않게 설정했다.

• 영상에서와 달리 나는, 테스트 커버리지 80%를 달성하지 못하면 CI과정에서 빌드가 실패하도록 설정했다, 배포 과정에서는 앞서 테스트 코드를 통해, 프로덕션 코드에 대한 검증이 완료되었다고 생각하고 따로 테스트 과정을 거치지 않도록 설정 했다.

테스트 커버리지를 계속 유지할 수 있을까?

 

테스트 커버리지를 계속 유지할 수 있을까?

영상에서는 설정한 테스트 커버리지를 만족하지 못하면 빌드가 안 되게 설정되어 있으니, 어떻게 보면 당연하게 테스트 커버리지를 유지할 수 있었다고 한다.

• 나 또한, 개인 프로젝트를 진행하면서 설정한 테스트 커버리지를 만족하지 못하면 빌드가 안되게 설정함으로써, 어느정도 강제적으로 테스트 커버리지를 유지할 수 있었던 것 같다고 생각한다.

영상에서는 높은 테스트 커버리지의 이점으로, 모든 코드가 테스트되었다는 사실에서 오는 자신감으로 인해, 배포를 자신있게(?) 할 수 있다고 합니다.

또한 거침없는 리팩토링을 할 수 있었다고 합니다.

• 리팩토링시, 테스트 코드가 존재한다면, 리팩토링후에 문제가 생긴다면 테스트가 실패할 것이니, 모든 코드가 테스트를 통해 피드백을 받을 수 있기에 자신있게 리팩토링을 할 수 있었다고 말한것 같습니다.
• 저 또한, 리팩토링 하려는 코드에 대한 테스트 코드가 없다면 리팩토링 시에 코드의 변경으로 인해 어떤 문제점이 생길지 알 수 없기에 테스트 코드가 없었다면 자신 있게 리팩토링을 진행하기 어려울 것 같았다는 생각이 듭니다.

프로덕션 코드에 대한 이해도 상승 도 높은 테스트 커버리지의 이점으로 영상에서 말해주고 있습니다.

이해가 충분하지 못하면 테스트를 작성할 수 없다. 라는 말에 저도 공감합니다.

• 자신이 작성한 코드가 어떻게 동작하는지 모르는 상태에서 해당 코드의 테스트 코드를 작성할 수 없기 때문이기도 합니다.

테스트 커버리지를 유지하면서 점점 테스트 작성이 쉬워진다고 말하고 있습니다.

• 저 또한, 이미 작성한 여러 테스트들을 참고해 새 테스트 작성시에 참고함으로써, 테스트 작성시간이 단축되는 것을 경험했습니다.
  • 테스트 작성시에, 계속해서 반복되는 코드 작성 패턴이 보인다면 Intelij의 Live Template 기능을 활용하면 반복되는 작업에 소요되는 시간을 좀 더 줄일 수 있지 않을까 생각해봅니다.
    • 참고 : https://siyoon210.tistory.com/176

IntelliJ Live Template으로 테스트 코드 빠르게 작성하기

인간의 의지는 도구로 대신할 수 있다 라는 설명과 함께, 영상속 발표자분께서는 Gradle의 JaCoCo 플러그인에 들어 있는 jacocoTestCoverageVerification 플러그인을 통해 설정한 테스트 커버리지를 만족하지 못하면 빌드가 실패하게 함으로써, 테스트 커버리지를 유지했습니다.( 해당 플러그인 설정법에 대해서는, 우아한 형제들 블로그 에 잘 나와 있으니 참고해주시기 바랍니다.)

---

테스트 커버리지를 유지하면서 느낀 단점

테스트 케이스 400개 기준으로, 전체 테스트를 실행하는데 1분이 넘는 시간이 걸리게 되는 문제가 발생했다고 설명하고 있습니다. 테스트를 실행할때마다, 1분씩 기다려야 하기도 하고, 배포 시에도 마찬가지로 테스트 때문에 1분씩 기다려야 하기 때문에 생산성의 저하로 이어질 수 있는 문제라 말하고 있습니다.

저 또한 프로젝트에서 74개의 테스트 케이스를 기준으로 약 13초의 시간이 소요되고 있습니다.

영상속 상황처럼 400개의 테스트 케이스를 기준으로 생각하게 되면 전체 테스트 케이스 실행에 1분이 넘는 시간이 소요될 것으로 예상됩니다.

영상에서는 테스트가 느려지는 주요 원인으로 테스트 시, 스프링 컨텍스트의 초기화를 원인으로 말해주고 있습니다.

저 또한 기존 13초가 걸리는 테스트의 원인으로, 인수 테스트 시에 DefaultSessionConfig를 각각의 인수 테스트에서 @Import 를 통해 처리해주고 있었는데, 이로 인해 테스트 성능이 느려진게 아닐까? 라는 의문을 갖고 다음과 같이 처리했습니다.

 

그림과 같이 각각의 ApiTest에서 @Import 를 통해 처리하던 것을

ApiTest라는 인수 테스트의 큰 틀을 담당하고 있는 클래스에서 @Import하도록 변경했습니다.

 

그 결과로, 테스트 수행 시간이 13초 → 11초로 개선된 것을 알 수 있습니다

 

영상에서는 Intelij에서 제공하는 async-profiler를 사용해 테스트 코드를 프로파일링 한 후 어떤 부분이, 병목 지점인지 파악한 후 개선을 했다 라고 설명해주고 있습니다.

그 중, 주요 병목 지점에 대해 다음과 같이 설명해주고 있습니다.

해당 문제들을 어떻게 해결했는지에 대해서는 영상을 참고해주시길 바랍니다.

 

테스트 속도 문제 뿐만아니라 테스트 하기 어려운 테스트 케이스들에 대해서도 말하고 있습니다.

예상 했던 어려운 테스트 들에 대한 부분은, 저 또한 발표자님과 생각이 비슷했습니다.

하지만 이런 부분들은 모킹을 사용함으로써 테스트를 진행할 수 있었습니다. 반면에 정말 어려운 코드는 바이트 코드를 테스트 하는 것이라 말하고 있습니다.( 영상은 코틀린을 기준으로 설명해주고 있어, 만약 궁금하신 분은 영상을 참고해주세요)

테스트 커버리지를 높게 유지하면서도 버그가 생기게 되었고 그에 대한 이유에 대해 다음과 같이 설명하고 있습니다.

Pitest라는 툴을 이용해, 테스트 하는 함수의 파라미터 값의 순서를 조작하는 등의 작업을 실행함으로써 Mutation Testing을 진행하고 있습니다.

 

Mutation Testing ? 

코드 변경 테스트(code mutation test) 라고도 하는 변경 테스트(Mutation Test) 는 테스터가 애플리케이션 소스 코드의 특정 구성 요소를 변경하여 소프트웨어 테스트 스위트가 변경 사항을 감지할 수 있도록 하는 화이트 박스 테스트의 한 형태입니다. 소프트웨어에 도입된 변경 사항은 프로그램에 오류를 일으키기 위한 것입니다. 돌연변이 테스트는 분석하는 애플리케이션이 아니라 소프트웨어 테스트 도구의 품질을 보장하기 위해 고안되었습니다.

또한 돌연변이 테스트는 일반적으로 단위 테스트를 수행하는 데 사용됩니다. 목표는 소프트웨어 테스트가 제대로 테스트되지 않은 코드나 다른 테스트 방법으로는 발견하지 못하는 숨겨진 결함을 감지할 수 있도록 하는 것입니다. 돌연변이(Mutation)라고 하는 변경은 기존 코드 줄을 수정하여 구현할 수 있습니다. 예를 들어, 문을 삭제하거나 복제하고, 참 또는 거짓 표현식을 변경하거나 다른 변수를 변경할 수 있습니다. 그런 다음 변이가 적용된 코드를 테스트하고 원래 코드와 비교합니다.

Mutation Testing은 상당히 많은 연산을 하는 비싼 작업이기에, 중요한 로직에만 부분적으로 적용하는 것이 좋습니다.

 

 

위 영상에서 나온 결론 입니다. 저 또한 영상을 보고 느낀점은 테스트 커버리지는 얼마든지 높일 수 있지만, 테스트 커버리지가 100%를 넘더라도 결국 버그는 발생할 수 밖에 없습니다. 따라서 테스트 작성시에, 단순히 커버리지를 높이기 위한 테스트를 작성하는 것이 아닌 테스트를 통해 프로덕션 코드의 어떤 부분을 검증하려고 테스트를 작성하는 것인지를 다시한번 생각해보며, 테스트를 작성하면 커버리지 뿐만 아니라, 버그도 없는 프로덕션 코드를 만들 수 있지 않을까 생각해봅니다.

또한 테스트를 지속적으로 작성하게 되면, 테스트 코드의 양이 많아져 테스트 코드 실행이 느려질 수도 있는데, 이또한 계속해서 개선해나가야 할 부분이라고 생각합니다.(테스트 코드 개선과 관련하여 정리가 잘 된 글이 있어 첨부 합니다.

테스트 코드 최적화 여행기 )

추가 학습할만한 키워드

• intelij async profiler
• Mutation Testing
  • pitest

참고 자료

• https://www.techtarget.com/searchitoperations/definition/mutation-testing
• https://www.youtube.com/watch?v=jdlBu2vFv58