단위 테스트의 희망편, 절망편과 성공적인 단위 테스트를 위한 지침

단위 테스트 : 희망편, 절망편

단위 테스트의 목표는 소프트웨어 프로젝트의 지속 가능한 성장이다.

단위 테스트의 적용 여부는 논쟁거리가 아니며 늘 적용해야한다.

그러나, 모든 테스트 스위트가 프로젝트에 좋은 결과만 가져오는 것은 아니다.

희망편

테스트를 포함한 프로젝트는 초반에 작업 속도가 테스트가 없는 프로젝트보다 느리지만

시스템이 복잡해질 수록 소프트웨어 엔트로피에서 이득을 본다.

소프트웨어 엔트로피는 시스템 내 무질서도를 말하는데,

테스트가 없는 프로젝트에서 소프트웨어 엔트로피는 저품질의 코드 형태로 나타나고

코드베이스를 신뢰할 수 없을 지경이 되면 그 소프트웨어는 안정적이라고 보기 어렵다.

코드베이스를 지속적으로 검증하는 테스트를 통해

회귀 현상(코드 수정 후 나타나는 버그)에 대한 안전망 역할을 하는 보험을 얻었다.

보험을 얻었으니 프로젝트 후반에도 개발 속도를 유지하며 소프트웨어를 확장할 수 있다.

부수 효과로 더 나은 설계를 얻을 수도 있다.

예를 들어,  코드가 서로 충분히 분리되어있지 않은 강결합(tight-coupling)의 저품질 코드를

단위 테스트를 쉽게 하기 위해 리팩토링 하는 케이스가 있다.

-> 그러나 낮은 결합도라고해서 프로젝트의 코드 품질이 좋다는 보장은 없다.

절망편

테스트가 포함된 프로젝트와 없는 프로젝트에 대한 차이는 얘기했으니

잘못된 테스트가 포함된 프로젝트에 대해서 얘기한다.

프로젝트 내에서 잘못된 테스트 스위트가 지속되면 

테스트를 해도 원하는 결과를 얻지 못하는 경우와 상황을 악화시키는 경우가 발생한다.

테스트가 잘못 작성된 프로젝트는 결국 침체 단계에 빠진다.

테스트 개수는 상당히 많지만 테스트 자체가 유지보수 되지 않고 버그를 유발한다면

잘못된 경고가 발생하고 회귀 오류에 도움이 되지 않는 결과를 보여준다.

테스트는 프로젝트에 도움이 돼야하는데

의미 없는 테스트만 양산한다면 ,

소프트웨어의 잠재적인 버그에 노출되는 부분을 넓히는 것에 불과하다.

고품질 테스트에만 집중해야하며,

고품질 테스트만 남아야한다.

성공적인 테스트를 위한 지침

•  커버리지 지표 ( 코드 커버리지, 분기 커버리지 )를 참고하되, 확신하지 말자.
   커버리지 지표는 좋은 부정 지표이자 나쁜 긍정 지표이다.
  
  단위 테스트를 할 수 없는 코드는 품질이 좋지 않다.
  단위 테스트를 할 수 있는 코드라도 품질을 보증할 수는 없다.
  
  
  
• 테스트 스위트를 개발 주기에 통합할 것
  
  
  
• 가치있는 테스트를 식별하고 가치있는 테스트를 작성할 것.
  이를 바탕으로 비즈니스 로직과 같은 도메인 모델, 즉, 
  코드베이스의 중요한 부분만 테스트 대상으로 지정할 것.
  
  이 외에,
    - 인프라 코드
    - 데이터베이스, 서드파티 시스템과 같은 외부 서비스
    - 모든 것을 하나로 묶는 코드
  가 있다. )
  

결국 테스트 기술은 코드 설계 기술

테스트의 가치가 높은 지, 낮은 지 식별하기 위해서는

기준틀이 필요하다.

가치가 높은 테스트를 작성하려면 코드 설계 기술이 필요하다.

 

기준틀로 테스트의 가치를 식별하는 것과

가치가 높은 테스트를 설계하는 것 중

기반 코드를 고려해야하므로 후자가 더 높은 노력을 필요로 한다.

참고

Unit Testing <블라디미르 코리코프>