01 단위테스트의 목표

• 단위테스트에 시간을 투자할때는 테스트에 드는 시간,노력을 가능한 줄이고, 이득을 최대화해야한다.

  단위테스트 현황

• 쓰고 버리는 프로젝트가 아니면, 단위테스트는 늘 적용해야한다.

  단위테스트의 목표

• 코드를 단위테스트 하기 어렵다면 코드 개선이 반드시 필요하다는 것을 의미.
• 코드베이스를 쉽게 단위테스트 할수있다고 해도 반드시 코드품질이 좋은것을 의미하지는 않는다.
• 단위테스트의 목표 : 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것.
• 개발 속도가 빠르게 감소하는 현상을 소프트웨어 엔트로피라고도 한다.(시스템 내 무질서도)
• 테스트는 새로운 기능 도입, 리팩터링 후 기존 기능이 잘 동작하는지 확인하는데 도움이 된다.
• 테스트는 초반에 노력이 필요하지만, 장기적으로 보면 비용을 메울 수 있다. ( 지속성과 확장성 측면 )
  1. 좋은 테스트와 그렇지않은 테스트
  • 잘못된 테스트를 가졌거나 테스트가 없는 프로젝트는 똑같이 침체단계에 있거나 버그가 많이 생긴다.
  • 코드베이스를 리팩터링할때 테스트도 리팩터링하라.
  • 코드 변경시 테스트 실행하라.
  • 테스트가 경고발생시 즉시 수정하라.
  • 코드베이스를 이해 하고자할때 테스트를 읽는데 시간을 투자하라.
    1. test suite 품질 측정을 위한 커버리지 지표
  • 커버리지 지표는 test suite 가 code를 얼마나 실행하는지 백분율로 나타낸다.
  • Code coverage
    • $coverage = codeNumExecutedByTest/allLineNum$
    • if문 문기 -> 조건부 연산자(?) 의 경우 라인수를 줄여버리면, 코드커버리지가 올라갈 수 있다.
  • Branch Coverage
    • $coverage = branchStatementExecutedByTest/allbranchStatement$
    • cove coverage의 라인수가지고 장난하는것을 방지할 수 있다.
  • 커버리지 지표에 의존할 수 없는 이유
    • 테스트 대상 시스템의 모든 가능한 결과를 검증한다고 보장할 수 없다. (100% 일지라도)
      • 검증(assertion) 이 없는 테스트는 커버리지만 높이고 테스트의 이점은 취할 수 없다.
    • 외부 라이브러리의 코드 경로를 고려할 수 있는 커버리지 지표는 없다.
      • 외부 라이브러리의 예외사항 전체를 테스트하지 않아도 커버리지는 높다.
  • 특정 커버리지 숫자를 목표로 하는것은 단위 테스트의 목표와 반대되는 그릇된 동기부여가 된다.
  • 시스템 핵심 부분은 커버리지를 높게 두는것이 좋다. 하지만 높은 수준을 요구사항으로 삼는것은 좋지 않다.
    1. 성공적인 test Suite
  • 개발 주기에 통합되어있다. (CI)
  • 코드베이스에서 가장 중요한 부분만을 대상으로 한다.
    • 비즈니스 로직 테스트가 시간 투자 대비 최고의 효율
    • 인프라코드, 외부서비스 및 종속성 테스트, 전체 테스트 등등

  • 최소한의 유지비로 최대의 가치를 끌어낸다.

정의 참고

1. TestCase : 기대결과를 만족하는지 기능을 테스트하는것.
2. TestSuite : 여러 테스트(메서드) 들을 하나로 묶은 것. 계획이나 분석등을 위해 TestCase를 categolize 하는 것.
3. TestRuns : 어떤 TestCase가 어떤시각에 어떤 유저에 의해 테스트될지 결정하는것. What is good coverage
   • 보통 80%가 좋은 목표라고 함.

     sonarqube에서 보통 codeCoverage를 사용함,

codeCoverage 는 필요한 곳에서만 체크하면 효율적일것같다. lombok coverage를 제외할수있는 방법 lombok.addLombokGeneratedAnnotation=true in lombok.config 확인해보자