가치있는 테스트를 작성하는 방법

• 코드의 4가지 유형(복잡도 또는 도메인 유의성 과 협력자 수를 이용해서 분류)
  • 도메인 모델과 알고리즘 : 복잡도 및 도메인 유의성(상) 협력자수(하)
    • 테스트하는 것이 가장 이로움
  • 간단한 코드 : 복잡도 및 도메인 유의성(하) 협력자수(하)
    • 테스트할 필요x
  • 컨트롤러 : 복잡도 및 도메인 유의성(하) 협력자수(상)
    • 간단한 테스트 필요
  • 지나 치게 복잡한 코드 : 복잡도 및 도메인 유의성(상) 협력자수(상)
    • 두부분으로 나누어야한다.(복잡도 및 도메인, 컨트롤러) → 가장 중요

코드가 더 중요해거나 복잡해질수록 협력자는 더 적어야 한다

좋지 않은 테스트를 작성하는 것보다는 테스트를 전혀 작성하지 않는 편이 낫다

• 험블 객체 패턴
  • 테스트가 가능한 부분을 추출 (험블래퍼)
  • 단일 책임원칙을 지키자
• 가치있는 테스트를 위한 리팩터링
  1. 암시적 의존성을 명시적으로 만들기 - 도메인 모델은 직접적으로든 간접적으로든 프로세스 외부 협력자에게 의존하지 않는 것이 깔끔
  2. 애플리케이션 서비스 계층 도입
  3. 애플리케이션 서비스 복잡도 낮추기

지침은 도메인 유의성이 있는 모든 전제조건을 테스트 해야하는 것이지만 도메인 유의성이 없는 전제 조건에는 시간을 들이지 마라

• 컨트롤러에서 조건부 로직 처리
  • 가장 효과적인 단계 : 저장소에서 데이터 검색 → 비즈니스 로직 실행 → 데이터를 다시 저장소에 저장
  • 로직이 명확하지 않을 때 세가지 방법
    1. 외부에 대한 모든 읽기와 쓰기를 가장자리로 밀어낸다.
    2. 도메인모델에 외부 의존성을 주입하고 비즈니스로직이 해당 의존성을 호출할 시점을 직접 결정
    3. 의사결정 프로세스 단계를 더 세분화, 단계별로 컨트롤러를 실행 [사용권장]
    • 세가지 특성을 맞춰야한다. (테스트 유의성, 컨트롤러 단순성, 성능)
    • → 위의 방법들은 항상 세가지 특성 중 최대 2가지를 가질 수 있다.

추상화 할 것을 테스트하기보단 추상화를 테스트하는 것이 쉽다

 

 

 

혼자 단위테스트라는 책을 읽으면서 생각에 흐름대로 적은 글입니다..
참고한 책은 단위 테스트라는 책입니다. ( http://www.yes24.com/Product/Goods/104084175 )