전에 Github에서 연동해서 사용할 수 있는 Travis CI를 소개한 적이 있다.(Travis CI 소개 #1, Travis CI 소개 #2 참고) Travis CI가 오픈소스 프로젝트를 관리하는데 큰 도움을 주고 있는데 Travis CI에 이어 비슷한 서비스들이 많이 등장하고 있다.

Coveralls

Github의 저장소들을 돌아다니다보면 왼쪽과 같은 아이콘을 본 적이 있을 것이다. 이는 Travis CI와 동일하게 Coveralls가 제공하는 뱃지인데 아이콘에서 알 수 있듯이 Coveralls는 소스코드의 커버리지를 측정하는 사이트다. 테스트코드를 작성해서 Travis CI에서 테스트를 돌리고 Coveralls을 이용해서 코드 커버리지를 확인해 볼 수 있다. 왼쪽 뱃지처럼 현재 커버리지를 뱃지로 보여주기 때문에 오픈소스를 확인할 때 테스트가 어느정도 이뤄지고 있는지도 빌드와 함께 확인해 볼 수 있다.(Travis에 비해서는 그리 많이 쓰이지는 않는듯)

혹 코드 커버리지에 익숙치 않은 사람들을 위해서 약간 부연설명을 하자면 소스코드에 대한 유닛 테스트를 작성하고 이 테스트가 소스코드의 어느정도를 테스트하고 있는지를 보여주는 것이 테스트 커버리지이다. 즉, 커버리지가 100%이면 테스트를 실행했을 때 모든 소스 코드가 최소한 1번 이상은 실행되어서 테스트 되었다는 것을 의미한다. 하지만 코드커버리지는 절대적으로 신용할 수 있는 값은 아니다. 그냥 "너무 낮으면 테스트를 많이 작성하진 않았구나?" 혹은 일정수준이상되면 어느정도는 테스트를 작성했구나 하는 정도로 참고값 정도로만 의미가 있다. 단순히 소스코드가 실행되었는지 여부만을 기준으로 커버리지를 나타내기 때문에 의도적인 어뷰징(오픈소스가 그럴일은 없겠지만)이 충분히 가능하다. 소스중에는 굳이 테스트를 작성하지 않아도 되는 부분이 분명히 있고 같은 소스에 대해서 경계값 예외값등 다양한 테스트를 작성해도 커버리지가 올라가는 것은 아니다. 커버리지는 그냥 딱 그정도로서만 의미가 있지만 어느 부분이 테스트되었는지 같이 나오기 때문에 누락된 부분을 확인하는데도 유용하긴 하다. 그래서 인지 Coveralls가 Travis처런 많이 쓰이는것 같지는 않다.

내가 셋팅한 Coveralls 셋팅이 온전치 않은 관계로(ㅠㅠ) Gitlab의 Coveralls를 보자.

Coveralls는 기본적으로 Github로 로그인을 하므로 Github의 저장소 기준으로 볼 수 있고 위 화면처럼 빌드별로 번호가 매겨지고 빌드마다 해당 빌드마다 커버리의 변동이 있는지 현재 커버리지가 얼마인지, 커밋정보 등과 함께 나타나고 있다. 위 화면에 나온 빌드는 모두 Travis에서 이뤄진 것임을 알 수 있다. 해당 빌드를 선택하면 좀 더 자세한 내용을 볼 수 있다.

Travis에서는 하나의 빌드에서 매트릭스로 여러 환경으로 테스트를 돌려볼 수 있기 때문에 하나의 빌드에 위처럼 여러 커버리지 측정결과가 나올수 있고 각각 Travis의 Job이 연결되어 있다. 하단에서 파일별 커버리지를 확인할 수 있고 파일을 클릭하면 테스트가 수행된 소스를 볼 수 있다.

녹색 부분이 테스트가 수행된 코드(테스트가 실행될때 실행된 코드)이고 빨간 부분은 누락된 부분이고 흰색 부분은 커버리지와 관련이 없는 부분이다. 녹색부분의 우측에 있는 숫자는 일반적인 커버리지 노구와 마찬가지로 해당 라인이 실행된 숫자이다.

Coveralls 사용

Coveralls를 사용하려면 Travis CI와 마찬가지로 저장소가 Github에서 호스팅하고 있어야 한다. 다음 화면의 가이드 문서에 나와있듯이 Ruby on Rails, Python, PHP, Node.js, C/C++, Scala, Go등 대부분의 언어를 지원한다.(음? 그러고보니 Java가 없네.) 그리고 Covaralls가 커버리지 데이터를 받아서 관리하는 역할만 하므로 CI 즉, 빌드를 해주는 무언가가 있어야 한다. 대표적으로는 계속 언급한 Travis CI가 있고 회사에서 많이 쓰는 Jenkins를 사용할 수도 있다. 빌드를 하고 테스트를 돌릴때 커버리지 데이터를 모아서 Coveralls에 전송하는 방식으로 동작하게 된다. 실제로 설정하는 방법은 언어별로 아주 다르고 대부분의 언어는 개인 개발자들이 만든 Coveralls 플러그인을 링크걸어놓았다. 실제로 연결하려면 각 언어별 가이드 문서를 확인해서 설정해야 하고 각각 언어를 여기서 설명하기는 무리이다. Travis CI를 사용하는 경우는 빌드설정에 Coveralls를 돌릴수 있도록 셋팅하고 Travis CI 설정파일인 .travis.yml에 Coveralls를 실행하는 명령어를 실행해서 커버리지가 수집되도록 한다.

상단의 Repositories 메뉴에서 Add A REPOSITORY를 누르면 자신의 계정이나 자신이 속한 Organization의 모든 저장소가 나오고 Coveralls에서 사용할 저장소를 키면 된다.(Private 저장소에서 사용하려면 유료결제를 해야한다.)

새로 저장소를 추가하면 다음과 같이 가이드 문서가 나타난다.

여러 설정에 대한 것이 나오지만 Travis CI 기본 계정을 쓰고 있다면 별로 셋팅할 것은 없다. 저장소 토큰이 필요하지만 Travis CI에서는 Travis의 것을 그대로 사용하므로 Jenkins등의 별도 CI를 사용할 때만 셋팅하면 된다. 위 화면에서 Settings부분에 Comment on pull requests?를 체크해 두면 다음과 같이 Pull Request가 왔을 때 커버리지를 보여준다.

이는 Travis CI가 동작하는 방식과 비슷한데 Travis CI가 Github와 연동하는 방법을 많이 개척해 놨기 때문에 Coveralls도 거의 그대로 따르고 있는 느낌이다. Travis CI가 Pull Request가 왔을때 미리 빌드를 돌려서 빌드 및 테스트 결과를 알려주기 때문에 Coveralls도 해당 Pull Request를 머지했을 때 커버리지가 어떻게 변경되는지 댓글을 추가해준다.

나는 Scala 프로젝트에서 사용해 보고 있는데 아직 문서가 상당히 부족한 느낌이다. 다른 언어에서는 어떤지 몰라도 Scala에서는 target 폴더까지 커버리지에 포함되서 커버리지가 좀 이상하게 나온다. 이것도 Scala의 coveralls 플러그인이 한글을 처리못해서 커버리지를 올리지 못하는 오류가 발생해서 이거 수정하느라고 한 2주는 플러그인 개발자랑 얘기하면서 겨우 처리했는데 Travis CI에서 올린 커버리지가 Coveralls에서는 500오류가 발생해서 이슈올려놓고 상황을 보고 있다.(이건 Coveralls의 문제인듯) 아직 좀 불안한 부분이 있는것 같기도 하지만 커버리지 서비스의 안정성이 프로젝트에 큰 영향을 주진 않으므로 그냥 쓰고 있다. 개인도 소스만 오픈해놓으면 개발하기 참 좋은 세상이다.