마틴 파울러로부터 테스트 커버리지의 의미를 찾다.

안녕하세요. yeTi입니다.
오늘은 마틴 파울러의 테스트 커버리지 를 계기로 삼아 테스트 커버리지를 알기위해 노력했던 경험을 공유하고 스스로 정의내린 테스트 커버리지의 의미를 공유하고자 합니다.

숙제

지난 4년간 풀지못한 숙제가 있습니다.

테스트 커버리지가 가지는 가치는 무엇일까?

테스트 커버리지를 100% 달성했다는 것은 무엇을 의미할까?

테스트 커버리지가 높아도 버그는 있어.

노력 1 - 소프트웨어 테스팅

2019년 07월 K-MOOC 의 강좌 중 하나인 소프트웨어 테스팅 을 접하게 됩니다.

해당 강의를 보며 완벽한 테스팅은 기술적으로 불가능하다는 것은 명시적으로 느끼고 테스트 기법이나 커버리지의 종류에 대해 접할 수 있는 기회가 되었습니다.

그러나 실무에서 사용할 수 있는것은 없어서 아쉬움이 남았습니다.

노력 2 - 토스 | SLASH 21 - 테스트 커버리지

시간이 흘러 2021년 4월 21일 토스에서 SLASH 21 을 개최합니다.

그 중 하나의 섹션인 토스 | SLASH 21 - 테스트 커버리지 100% 가 눈에 띄어 흥미롭게 참관 했습니다.

섹션을 진행하신 이응준님의 노력에는 감탄의 박수가 나왔지만 스스로는 그래서 왜 커버리지 100% 를 향해야하는지는 의구심으로 남아있었습니다.

왠지 가치는 없이 형식에 따른 수치를 맹목적으로 믿는것은 아닌가라는 생각도 들었습니다.

기회 1 - XP 의 만남

2022년 10월 우연한 기회에 XP 를 읽게 되었는데 유의미하게 커버리지를 말할 수 있는 개념을 접합니다.

실천 방법 중 하나인 10분 빌드 입니다.

10분 빌드의 가치는 무엇이냐?

테스트를 통하여 팀의 신뢰를 높이는 것은 중요하지만 테스트가 과하면 개발의 병목 지점으로 변이합니다.

이에 실리콘 밸리에 있는 스타트업에서는 경험적으로 10분 빌드를 사용한다고 합니다. 10분의 의미는 개발자가 잠시 휴식을 취할 수 있는 정도의 가치있는 시간입니다.

XP 에서의 커버리지의 의미는 우리가 개발을 함에 있어서 테스트를 기반으로 신뢰를 형성할 수 있으면서 개발자들이 잠시 휴식을 취할 수 있는 것입니다.

XP를 읽으면서 10분 빌드 개념이 그럴듯하게 느껴져 실무에서도 도입해본 결과.

테스트 코드가 익숙하지 않은 사람들이 10분 빌드 타임을 가진다는 것은 생각보다 먼 미래의 얘기라는 것입니다.

따라서 잘 모르니까 효율적인 테스트 코드를 위해 공부를 하며 머뭇거리는거 보다 비효율적인 테스트 코드라도 만들어 놓는것이 중요합니다.

기회 2 - 조환님과의 만남

그러다 2023년 2월 8일 설로인의 개발리더이신 조환님을 만나게 됩니다.

조환님과의 만남을 통해 테스트 코드를 프로그램의 사양서로써의 기능의 유효성을 공감할 수 있었고 QA팀이 없는 것을 테스트 커버리지로 어떻게 설명할 수 있는지를 질문해 봤습니다.

우리가 품질을 위해 최소한의 노력은 하고 있다는 증거

조환님도 테스크 커버리지가 가지는 수치가 품질을 증명하지는 않지만 적어도 우리가 품질을 위해 이정도의 노력은 하고 있다 정도는 말할 수 있는 지표라고 말씀하셨습니다.

이성적으로 납득이 가는 답변이었습니다.

기회 3 - 테스트 카버리지의 쓰임새

같이 XP 독서 모임을 하는 유영모 님께서 테스트 커버리지를 재미있는 쓰임새로 활용하시는 것을 보고 새로운 시야를 가질 수 있었습니다.

주니어 개발자들이 테스트 코드로써 커버리지라는 수치를 높여가는 재미의 일종으로 활용하시는 것을 들으면서 테스트 커버리지를 꼭 품질의 증명으로만 보기보다는 프로그래머들이 자연스럽게 테스트를 작성하는 재미 요소로 활용할 수 있다는 경험은

그 동안 테스트 커버리지와 품질이라는 관계를 맺으려는 경직된 생각을 다른 시각으로 볼 수 있어서 재미있게 다가왔습니다.

테스트 커버리지

이제는 마틴 파울러가 말하는 테스트 커버리지 까지 도달했습니다.

그 동안 막연하게 테스트 커버리지의 가치를 찾아 방황하던 시간들이 유의미한 가치로 정의되는 순간인거 같아 안도의 숨이 내숴집니다.

이 글을 공유해주신 영모님께 감사의 말씀을 전해드렸습니다.

마틴 파울러는 테스트 커버리지를 다음과 같이 말합니다.

Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are.

그 동안 테스트 커버리지의 수치가 가지는 의미를 찾아보려는 노력을 무의미한 것으로 만들어주는 말에 기쁨이 느껴졌습니다.

그리고 테스트 커버리지를 아직 테스트 되지 않은 부분을 찾아보는 도구로 활용한다는 것이 유용한 쓰임새로 설명하고 있다는 느낌을 받았습니다.

If you make a certain level of coverage a target, people will try to attain it. The trouble is that high coverage numbers are too easy to reach with low quality testing. At the most absurd level you have AssertionFreeTesting. But even without that you get lots of tests looking for things that rarely go wrong distracting you from testing the things that really matter.

맹목적인 수치를 달성하기 위해 작성한 테스트 들이 정작 중요한 테스트에 방해가 될 수 있다는 부분도 수치적인것이 무의미한 형식으로 전락할 수 있다고 말하는거 같습니다.

If you are testing thoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s

그래도 신중하게 테스트를 작성하는 팀의 커버리지가 80 ~ 90% 정도 될것이라고 말하는 것을 보면 꽤 높은 수준을 기본적으로 유지하고 있다라는 생각이 듭니다.

I would say you are doing enough testing if the following is true:

• You rarely get bugs that escape into production, and
• You are rarely hesitant to change some code for fear it will cause production bugs.

그리고 굳이 테스트 커버리지를 측정하지 않더라도 프로덕션 환경으로 빠져나가는 버그가 거의 없거나 프로덕션 버그를 일으킬까 봐 일부 코드를 변경하는 것을 주저하는 경우가 거의 없다면 충분히 테스트 코드를 작성하고 있다고 말합니다.

빈대로 말해보면 프로덕션 환경으로 빠져나가는 버그가 있거나 프로덕션 버그를 일으킬까 봐 일부 코드를 변경하는 것을 주저한다면 테스트 커버리지가 부족하다고 인식할 수 있습니다.

Some people think that you have too many tests if they take too long to run. I'm less convinced by this argument. You can always move slow tests to a later stage in your deployment pipeline, or even pull them out of the pipeline and run them periodically. Doing these things will slow down the feedback from those tests, but that's part of the trade-off of build times versus test confidence.

그리고 XP 에서 말하는 10분 빌드를 넘어가더라도. 혹은 정말 테스트가 많아 오래 걸리더라도 전략적으로 유의미하게 구성할 수 있다고 말합니다.

So what is the value of coverage analysis again? Well it helps you find which bits of your code aren't being tested. [1] It's worth running coverage tools every so often and looking at these bits of untested code. Do they worry you that they aren't being tested?

마지막으로 테스트 커버리지는 테스트되지 않은 코드를 찾는 데 도움이 되기 때문에 커버리지 도구를 자주 실행하여 테스트되지 않은 코드 부분을 살펴보는 것이 증요하다고 마무리합니다.

결론

테스트 커버리지를 수치로 품질을 증명하는데 사용하지 말고 테스트되지 않은 코드 부분을 살펴보는 쓰임새를 가지도록 활용하는게 좋다는 생각이 들었습니다.

그리고 만일 테스트 커버리지를 활용하지 않더라도 프로덕션 환경으로 빠져나가는 버그가 있거나 프로덕션 버그를 일으킬까 봐 일부 코드를 변경하는 것을 주저한다면 테스트 커버리지가 부족하다고 인식하고 테스트 비중을 높여야 합니다.

맹목적으로 수치를 위해 테스트 코드를 작성하는 것은 무가치하지만 마틴 파울러의 경험적으로 테스트를 신중하게 작성하는 팀은 80 ~ 90%의 코드 커버리지를 가진다고 합니다.

테스트 커버리지는 진단 키트일 뿐입니다.