가치있는 단위 테스트를 위한 리팩터링

Crow·2022년 8월 17일
0

Unit Testing

목록 보기
4/5
  • 네 가지 코드 유형 알아보기
  • 험블 객체 패턴 이해
  • 가치있는 테스트 작성

정리

  • 코드 복잡도는 코드에서 의사 결정 지점 수에 따라 명시적으로(코드) 그리고 암시적으로(코드가 사용하는 라이브러리)정의

  • 도메인 유의성은 프로젝트의 문제 도메인에 대해 코드가 얼마나 중요한지를 보여줌
    (복잡한 코드는 종종 도메인 유의성이 높고, 그 반대의 경우도 있지만, 모든 경우에 100% 해당하지 않음)

  • 복잡한 코드와 도메인 유의성을 갖는 코드는 해당 테스트 희귀 방지가 뛰어나기 때문에 단위 테스트에서 가장 이로움

  • 협력자가 많은 코드를 다루는 단위 테스트 유지비가 많이 들어감
    (이러한 테스트는 협력자를 예상 상태로 만들고 나서 상태나 상호 작용을 확인하고자 공간을 많이 필요로 함)

  • 모든 제품 코드는 복잡도 또는 도메인 유의성과 협력자 수에 따라 네 가지 유형의 코드로 분류
    1) 메인 모델 및 알고리즘(복잡도 또는 도메인 유의성이 높음, 협력자가 거의 없음)은 단위 테스트에 대한 노력 대비 가장 이로움

    2) 간단한 코드(복잡도와 도메인 유의성이 낮음, 협력자가 거의 없음)테스트할 가치가 전혀 없음

    3) 컨트롤러(복잡도와 도메인 유의성이 낮음, 협력자가 많음)는 통합테스트를 통해 간단히 테스트 해야함

    4) 지나치게 복잡한 코드(복잡도 또는 도메인 유의성이 높음, 협력자가 많음)는 컨트롤러와 복잡한 코드로 분할해야함

  • 코드가 중요하거나 복잡할수록 협력자가 적어야함

  • 험블 객체 패턴은 해당 코드에서 비즈니스 로직을 별도로 클래스로 추출해 복잡한 코드를 테스트 할 수 있는데 도움이됨
    ( 그 결과 나머지 코드는 비즈니스 로직을 둘러싼 얇은 험블 래퍼, 즉 컨트롤러가 됨)

  • 육각형 아키텍처와 함수형 아키텍처는 험블 객체 패턴을 구현함

    육각형 아키텍처: 비즈니스 로직과 프로레스 외부 의존성과의 통신을 분리하도록 함

    함수형 아키텍처: 프로세스 외부 의존성 뿐만 아니라 모든 협력자와의 통신과 비즈니스 로직을 분리함

  • 코드의 깊이와 너비의 관점에서 비즈니스 로직과 오케스트레이션 책임을 생각해라
    (코드는 깊을 수도 있고(복잡하거나 중요함) 넓을 수도 있지만(협력자가 많음), 둘 다 적용할 순 없음)

  • 도메인 유의성이 있으면 전제 조건을 테스트하고,
    그 외의 경우에는 테스트하지 않는다

  • 비즈니스 로직과 오케스트레이션을 분리할 때는 다음과 같이 세 가지 중요한 특성이 존재함
    1) 도메인 모델 테스트 유의성: 도메인 클래스 내 협력자 수와 유형에 대한 함수
    2) 컨트롤러 단순성: 컨트롤러에 의사 결정 지점이 있는지에 따라 다름
    3) 성능: 프로세스 외부 의존성에 대한 호출 수로 정의

  • 항상 세 가지 특성 중 최대 두 가지를 가질 수 있음
    1) 외부에 대한 모든 읽기와 쓰기를 비즈니스 연산 가장자리로 밀어내기: 컨트롤러를 단순하게 유지하고 도메인 모델 테스트 유의성을 지키지만, 성능이 저하됨

    2) 도메인 모델에 프로세스 외부 의존성 주입하기: 성능을 유지하고 컨트롤러를 단순하게 하지만, 도메인 모델의 테스트 유의성이 떨어짐

    3) 의사 결정 프포세스 단계를 더 세분화하기: 성능과 도메인 모델 테스트 유의성을 지키지만, 컨트롤러의 단순함을 포기함

  • 의사 결정 프로세스 단계를 더 세분화 하는것이 장단점을 고려할 때 가장 효과적인 절충임
    또한 다음 두 가지 패턴을 사용해 컨트롤러 복잡도 증가를 완화할 수 있음
    1) CanExecute/Execute 패턴은 각 Do() 메서드에 대해 CanDo()를 두고, CanDo()가 성공적으로 실행되는것을 Do()의 전제 조건으로 한다
    이 패턴은 Do() 전에 CanDo()를 호출하지 않을 수 없기 때문에 컨트롤러의 의사 결정을 근본적으로 제거함

    2) 도메인 이벤트는 도메인 모델의 중요한 변경 사항을 추적하고 해당 변경 사항을 프로세스 외부 의존성에 대한 호출로 변환하며
    이 패턴으로 컨트롤러에서 추적에 대한 책임이 없어짐

  • 추상화할 것을 테스트 하기보다는 추상화를 테스트 하는것이 더 쉬움
    도메인 이벤트는 프로세스 외부 의존성 호출 위의 추상화에 해당함
    도메인 클래스의 변경은 데이터 저장소의 향후 수정에 대한 추상화에 해당함


주석

오케스트레이션: 컴퓨터 시스템과 애플리케이션, 서비스의 자동화된 설정, 관리, 조정을 의미합니다.

profile
어제보다 개발 더 잘하기 / 많이 듣고 핵심만 정리해서 말하기 / 도망가지 말기 / 깃허브 위키 내용 가져오기

0개의 댓글