8P by ohjongin 2022-06-22 | favorite | 댓글 9개

이런 간단한 코틀린 코드도 모든 분기를 테스트하는 것은 불가능에 가까울 정도로 어렵다. 코틀린이 이 코드를 바이트코드로 컴파일하면서 코드 작성자가 의도하지 않은 분기를 만들어내기 때문이다.

when(answer) {
"yes" -> true
else -> false
}

코틀린은 코드를 작성하는 개발자에게 편리한 기능을 많이 제공해주는 한편, 바이트코드로 컴파일하면 이와 같이 유저에게 드러나지 않는 분기문 역시 많이 만들어낸다. jvm 플랫폼에서 가장 널리 쓰이는 테스트 커버리지 도구인 jacoco는 브랜치 커버리지를 계산할 때 바이트코드 기준으로 계산하기 때문에 코틀린 언어를 사용하는 개발자가 눈치채지 못한 브랜치도 커버할 것을 요구할 수 있다. 따라서 코틀린 개발자가 테스트 커버리지 100%를 맞추려고 시도한다면 위와 같은 경우 디컴파일을 해 보아야 하는 경우가 있고, 더 운이 나쁘면 디컴파일에 실패해서 바이트코드를 직접 보고 어떤 브랜치가 있는지 확인해야 하는 경우도 있다.

커버리지 추적을 100% 찍으려고 코드를 비트는건 주객전도 느낌이네요

코드는 비틀리지 않았죠. 인간적 관점에서 더 편한 다른 방법이 있을뿐이죠.

국방(무기체계) 분야는 방사청의 지침에서 코드 커버리지 100%를 요구합니다.
현실적으로 100% 달성은 어렵지만 대신 커버 안되는곳은 하나하나 왜 커버가 안 되는지 설명을 달아야 하는걸로 알고있어요.

광기의 테스트 100%좌…

enum / sealed / boolean 의 분기 경우에는 제대로 처리되지 않으면 kotlin 1.6에서는 경고가, 1.7부터는 오류가 나도록 컴파일러가 바뀌었습니다.

https://youtrack.jetbrains.com/issue/KT-47709

slash 21에서 내용 잘 봤습니다 ㅎㅎ

아~ slash 21에서 나온 내용이었군요... 저는 지인 트위터에서 처음 봐서요... 뒷북 죄송...