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

제품 코드와 테스트 코드는 본질적으로 관련돼 있기 때문에 테스트 스위트를 개선시키기 위해서는 제품 코드를 리팩토링해야 한다. 다른 방도는 없다.

좋지 않은 테스트를 작성하는 것보다는 테스트를 작성하지 않는 것이 더 좋다. 가치가 별로 없는 테스트는 좋지 않은 테스트이다.

리팩토링할 코드 식별하기

• 코드 복잡도와 도메인 유의성

  • 코드 복잡도 → 코드 내 분기(결정) 지점 수로 정의하고, 클수록 복잡도가 더 높아짐 (복잡한 코드는 보통 도메인 유의성이 높다.)

  • 도메인 유의성 → 도메인에 대해 얼마나 의미있는지를 나타냄. 즉, 최종 사용자의 목표와 직접적인 연관성이 있으면 유의성이 높다.

• 코드 내의 협력자 수

  • 프로세스 외부 의존성 → 외부 애플리케이션 또는 서비스와 상호작용하는 경우

  • 가변 의존성 → 의존하는 객체가 시간에 따라 다른 요소로 변경되는 경우

  • 협력자가 많은 테스트는 의존성을 목킹하고 준비하는 코드가 필요하므로 테스트 크기가 늘어나 유지보수성이 낮아진다.

코드의 네 가지 유형

• 도메인 모델과 알고리즘

  • 협력자가 거의 없으며, 도메인 모델이거나 도메인과 관련 없지만 복잡한 알고리즘을 가진 코드

  • 단위 테스트를 수행하기 가장 적절한 유형, 복잡하거나 중요한 로직은 회귀방지가 뛰어나기 때문에 가치가 있다.

  • 도메인 유의성이 높은 코드는 프로세스 외부 협력자를 사용해선 안된다.

• 간단한 코드

  • 간단한 코드는 대부분 협력자가 없고 복잡도와 도메인 유의성이 거의 없는 편이라 테스트를 작성할 필요가 없다.

• 컨트롤러

  • 비즈니스에 중요한 작업을 하지 않고, 분리된 도메인 로직과 외부 의존성을 컨트롤하는 부분

  • 통합 테스트로 간단히 테스트

• 지나치게 복잡한 코드

  • 테스트가 필요하지만 가장 작성하기 어려운 유형 (협력자가 많고, 복잡성이 높은 유형)

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

  • 복잡한 코드와 컨트롤러로 분리하는 리팩토링이 필요하다.

코드에 중요한 로직이 포함되있거나 복잡성이 증가할수록 반비례해서 협력자 수가 적어져야 한다.

지나치게 복잡한 코드 리팩토링하기

지나치게 복잡한 코드를 도메인 모델과 알고리즘과 컨트롤러 두 부분으로 쪼개보자.

험블 객체 패턴

테스트하기 쉬운 비즈니스 로직과 테스트하기 어려운 프로세스 외부 의존성을 분리하는 디자인 패턴

테스트하기 어려운 부분이 험블 객체(컨트롤러)가 된다.

• 헥사고날 아키텍처, 함수형 아키텍처는 험블 객체 패턴을 구현한다.

• 지나치게 복잡한 코드에서 로직을 추출해 코드를 테스트할 필요가 없도록 만든다.

• 험블 객체 패턴은 단일 책임 원칙을 따라 비즈니스 로직과 오케스트레이션으로 분리한다.

  • 코드의 깊이와 너비 관점으로 책임을 나눌 수 있다. 깊을수록 복잡하고 넓을수록 협력자가 많다. 둘 다는 없다.

• 코드가 복잡하고 중요한 경우 도메인 모델과 알고리즘 유형으로, 협력자와 상호작용하는 코드를 컨트롤러 유형으로 옮긴다.

오케스트레이션이란 애플리케이션을 관리하고 실행하는 컨트롤러의 역할을 의미한다.

단계 별로 리팩토링하기

1. 암시적 의존성을 명시적으로 만들기

• 관심사를 분리해서 의존성을 명시적으로 주입하는 형태로 리팩토링한다.

• 테스트에서 의존성을 목으로 처리할 수 있게 된다.

• 단, 도메인 모델은 직접적이든, 간접적이든 프로세스 외부 협력자에게 의존하지 않는 것이 좋다.

2. 애플리케이션 서비스 계층 도입

• 도메인 모델은 일반적으로 내부 의존성에만 의존해야하기 때문에 외부 시스템과 직접 상호작용하는 것을 피해야 한다.

• 도메인 모델이 외부 시스템과 직접 상호작용하는 문제를 해결하기 위해 험블 객체(컨트롤러)로 책임을 옮겨야 한다.

• 애플리케이션 서비스 계층의 역할은 복잡도나 도메인 유의성과 관련된 로직이 아니라 오케스트레이션만 해당된다.