SLASH21 #테스트 커버리지 100%

클린코더 - 테스트 커버리지 100% 권장, 프로덕션 코드 4천, 테스트코드 6천, 커버리지가 낮으면 배포되지 않게 설정

모든 코드가 자신있게 커버되는 환경이 되면 자신있게 배포를 누를 수 있게 된다, 배포를 하고 나고도 눈치보는 일이 없어진다, 거침없는 리팩토링 가능 - 코드 가독성 유지

불필요한 프로덕션 코드가 제거된다 - 남아 있는 코드는 테스트해야되니까..

완벽히 프로덕션 코드를 이해하게 된다 - 그래야 테스트를 할수 있으니

테스트 작성이 점점 쉬워짐

테스트 커버리지를 올리기 위해서 가장 필요한건 믿음, 시간

• 어떤 코드는 테스트 할 수 있다는 믿음
• 프로젝트 초기부터 커버리지가 높은 상태로 유지하는게 중요
• 인간의 의지는 도구로 대신할 수 있다.
  • Gradle의 JaCoCo 플러그인 jacocoTestCoverageVerification - 빌드가 안되게 해줌
  • ByteCode단위 커버리지 측정 도구

어려움

테스트 케이스가 많아지면서 실행 시간이 많아지면서 생산성이 떨어진다

해결법들...

• 스프링 애플리케이션 컨텍스트 로딩(부하가 크다) - 전부 제거
• async-profiler를 이용해 성능 profile해서 성능이 느려지는 위치를 찾음
• 하드웨어 update... !! 테스트 1600개 커버리지가 100% 인데 6s

DB, 네트워크, 프레임워크, 랜덤, 시간 - 모킹을 이용해서 해결

진짜어려운건 바이트 코드 테스트 - 커버리지 기준이 byte code 기준이기 때문

코틀린 - > bytecode -> java로 역컴파일 하면 Null인지 검사하는 분기가 새로 나온다!!!

커버리지에 예외시켜주기도 한다...

그래도 버그는 나옴

• 테스트 케이스가 부족할때 (커버리지 도구를 너무 맹신하지 말것)
  • 프로덕션 코드를 무작위로 조작했을때 테스트가 통과하는지 확인
  • pitest.org - 뮤테이션 테스팅을 해준다
• 요구사항을 작성한 사람이 인수 테스트 진행 - JUnit5의 TestExecutionListener 를 활용하여 마크다운 문서로 만드는 app을 만듬
• 계약을 관리해 주는 Pactflow라는 도구가 존재