본문으로 건너뛰기

Goal-Of-Unit-Testing

1 단위 테스트 현황​

  • 기업용 애플리케이션 개발 프로젝트는 거의 모두 단위 테스트가 적용돼 있다
  • 수많은 단위 테스트와 통합 테스트를 통해 좋은 코드 커버리지를 달성하고 있다
  • 제품 코드와 테스트 코드의 비율이 점점 높아지고 있다
  • 단위 테스트에 대한 논쟁은 이제 단위 테스트를 작성해야 하는가? 에서 좋은 단위 테스트를 작성하는 것은 어떤 의미인가? 로 바뀌었다

2 단위 테스트의 목표​

  • 단위 테스트 활동이 더 나은 설계로 이어진다. 하지만 더 나은 설계는 단위 테스트의 주목표는 아니고 부수 효과일 뿐이다
  • 단위 테스트의 궁극적인 목표는 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것이다

테스트가 없는 일반 프로젝트

  • 처음에는 발목을 잡을 것이 없으므로 빨리 시작할 수 있다
  • 아직 잘못된 아키텍쳐 결정이 없고 걱정할 만한 코드가 있지도 않다
  • 시간이 지나면서 점점 더 많은 시간을 들여야하고 결국 개발 속도가 현저히 느려지고, 심지어 전혀 진행하지 못할 정도로 느려질 수 있다
  • 개발 속도가 빠르게 감소하는 이러한 현상을 소프트웨어 엔트로피라고도 한다
  • 코드베이스에서 무언가를 변경할 때마다 무질서도(엔트로피)는 증가한다
  • 지속적인 정리와 리팩터링 등과 같은 관리를 하지 않고 방치하면 시스템이 점점 더 복잡해지고 무질서해진다

테스트가 있는 프로젝트

  • 테스트는 안전망 역할을 하며, 대부분의 회귀에 대한 보험을 제공하는 도구라 할 수 있다
  • 테스트는 새로운 기능을 도입하거나 새로운 요구 사항을에 더 잘 맞게 리팩터링한 후에도 기존 기능이 잘 작동하는지 확인하는데 큰 도움이 된다
  • 단점은 초반에 상당한 노력이 필요하다는 것
  • 그러나 프로젝트 후반에도 잘 성장할 수 있도록 하므로 장기적으로 보면 그 비용을 메울 수 있다
  • 코드베이스를 지속적으로 검증하는 테스트 없이는 개발이 쉽게 확장되지 않는다
  • 지속성과 확장성이 핵심이며 이를 통해 장기적으로 개발 속도를 유지할 수 있다

회귀

회귀는 특정 사건(일반적으로 코드 수정)후에 기능이 의도한 대로 작동하지 않는 경우다. 소프트웨어 버그와 회귀라는 용어는 동의어이다

2.1 좋은 테스트와 좋지 않은 테스트를 가르는 요인​

  • 단위 테스트가 프로젝트 성장에 도움이 되는것은 맞지만 테스트를 작성하는 것만으로는 충분하지 않다
  • 좋지 않은 테스트는 테스트가 부재한 프로젝트와 비교하여 초반에 코드가 나빠지는 것을 늦출 수 있지만 거시적 관점에서 큰 차이가 없다
  • 좋지 않은 테스트는 잘못된 경고가 발생하고, 버그를 발견하는데 도움이 되지 않으며, 유지 보수가 어렵고 느리다
  • 이러한 테스트를 더 많이 실행하더라도 단위 테스트의 목표를 달성할 수 없다
  • 지속 가능한 프로젝트 성장을 위해서는 고품질 테스트에만 집중해야 한다. 이러한 테스트만이 테스트 스위트에 남을 만한 테스트 유형이다

3 코드 커버리지​

  • 테스트 스위트의 품질 측정을 위해 코드 커버리지 지표를 사용하기도 한다
    • 일반적으로 커버리지 숫자가 높을수록 더 좋다
  • 하지만 코드 커버리지는 중요한 피드백을 주더라고 테스트 스위트 품질을 측정하는데 사용할 수 없다
  • 코드 커비리지가 성공적인 테스트 스위트를 보장하지 않기 때문에 개발자 스스로 좋은 테스트를 구별할 줄 알아야한다
  • Code-Coverage.md의 Code Coverage와 테스트 스위트의 품질 참고

4 좋은 테스트 스위트의 특성​

4.1 개발 주기에 통합돼 있다​

  • 모든 테스트는 개발 주기에 통합돼야 한다
  • 테스트를 빌드 시스템에 통합한다
  • 이상적으로는 코드가 변경될 때마다 아무리 작은 것이라도 실행해야 한다

4.2 코드베이스 중 가장 중요한 부분만을 대상으로 한다​

  • 단위 테스트 측면에서 코드베이스의 모든 부분을 똑같이 주목할 필요는 없다
  • 시스템의 가장 중요한 부분에 단위 테스트 노력을 기울이고 다른 부분을 간략하게 또는 간접적으로 검증하는 것이 좋다
  • 애플리케이션에서 가장 중요한 부분은 비즈니스 로직이 있는 부분이다
  • 비즈니스 로직 테스트가 시간 투자 대비 최고의 수익을 낼 수 있다
  • 다른 부분은 세 가지 범주로 나눌 수 있다
    • 인프라 코드
    • 데이터베이스 같은 외부 서비스 및 종속성
    • 모든 것을 하나로 묶는 코드
  • 통합 테스트와 같이 도메인 모델을 넘어 코드베이스에서 중요하지 않은 부분을 포함해 시스템이 전체적으로 어떻게 동작하는지 확인할 수 있다
    • 이는 좋은 방법이지만 초첨은 도메인 모델에 머물러 있어야 한다

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

  • 테스트를 시스템에 통합하는 것만으로 충분하지 않으며 도메인 모델에 높은 테스트 커버리지를 유지하는 것도 충분하지 않다
  • 가치있는 테스트를 식별하고 가치 있는 테스트를 작성하는 것이 가장 중요하다
  • 가치가 유지비를 상회하는 테스트만 스위트에 유지하는 것이 중요하다