토스 빗금 21 행사 요약 - 테스트 커버리지 100%

토스의 빗금 21(토스ㅣSLASH 21) 행사 요약입니다.

영상 속 내용을 정리한 것이기 때문에 일부 잘못된 내용이 포함될 수 있으며 다르게 이해한 내용을 기재할 수도 있습니다. 발표 영상을 먼저 참고해주세요.

 

테스트 커버리지 100%

이용준 토스뱅크(가칭) Server Developer

youtu.be/jdlBu2vFv58

콘텐츠 진행 방식이 맘에 듭니다. 다른 세션에 비해 짧지 않은 영상임에도 불구하고 결과를 먼저 이야기하고 그 과정에서 해결한 문제에 대해 설명하고 있습니다. 그래서인지 뭔가 쉽게 설명하는 느낌이네요.

 

인간의 의지는 도구로 대신할 수 있다

 

오호 그렇군요. 뭔가 100%를 달성하기 위해서는 끊임없는 노력과 의지가 필요할 것 같은데 요즘은 도구로 그걸 할 수 있군요. 마치 만보기 같은 걸까요?

 

Jacoco 플러그인 설명을 하는데 일단 공식문서는 이거고요.

docs.gradle.org/current/dsl/org.gradle.testing.jacoco.tasks.JacocoCoverageVerification.html

JacocoCoverageVerification - Gradle DSL Version 7.0

우아한 형제들 개발 블로그에서도 비슷한 내용을 다루고 있습니다.

woowabros.github.io/experience/2020/02/02/jacoco-config-on-gradle-project.html

Gradle 프로젝트에 JaCoCo 설정하기 - 우아한형제들 기술 블로그

중간에 테스트가 느려지는 원인에 대한 기술적인 설명이 나열되는데 그 부분은 일단 넘어가고 마지막 부분에 테스트로 스펙 문서 만들기라는 주제가 잠시 등장합니다.

 

테스트로 스펙 문서 만들기

일단 아이디어는 테스트 실행 시 JUnit5의 TestExecutionListener를 사용해 테스트 이름을 수집하고 수집한 테스트 내용을 기반으로 마크다운 형식의 스펙 문서를 작성하는 겁니다.

junit.org/junit5/docs/5.0.3/api/org/junit/platform/launcher/TestExecutionListener.html

 

화면 상으로는 꽤 스펙 문서처럼 보이는 문서가 만들어졌습니다.

테스트 케이스를 읽어서 저 정도 수준의 스펙 문서를 만들 수 있다면 대단한 일인 것 같습니다.

하지만 이 과정에서 몇몇 문제가 생겨(주로 사람에 대한) 더 이상 진행은 하지 못했다고 합니다.

• 이해하기 쉬운 테스트 케이스를 작성하기 위한 노력이 필요
• 항상 설명에 노력을 기울이긴 힘들다

그렇게 문서 품질은 점점 떨어지고 신뢰할 수 없는 문서가 되어버리는 거죠.

물론 맘만 먹으면 테스트 코드처럼 없는 경우 빌드를 실패하게 제한해버릴 수도 있겠지만, 실제 제품에 스펙 문서가 필수일까 하는 의문 때문에 더 이상 진행하지 않은 것 같습니다.

개발자 입장에서는 코드를 직접 보면 되니깐 문서가 없더라도 당장 우회할 길이 보이니깐요.

 

* 문서화 작업을 위해 먼저 검토한 건 cucumber였다고 합니다. 자연어로 시나리오를 작성하고 이를 기반으로 테스트 코드를 생성하기 때문에 오히려 적합한 방법이었으나, cucumber가 생성해주는 문서의 가독성이 부족하고 원하는 방식으로 커스터마이징 하는데 제약이 있었기 때문에 TestExecutionListener를 선택했다고 합니다.

cucumber.io/

BDD Testing & Collaboration Tools for Teams | Cucumber