•
우리는 우리가 직접 변경할 수 없는 코드를 가져와서 사용하곤 한다.
•
이런 코드(라이브러리, API 호출)들을 사용하면 테스트가 불필요하다고 오해하기 쉬운데, 실제로 의미 있는 코드를 새로 작성하지 않기 때문이다.
•
라이브러리 호출로 지저분해진 시스템은 자신이 직접 작성한 시스템에 비해 여러 가지 면에서 다루기 힘들다.
◦
첫 번째 이유는 시스템 구조를 개선할 방법을 알기 어렵다는 점이다. 단지 API 호출만 확인할 수 있기 때문이다.
◦
두 번째 이유는 API를 직접 소유하지 않기 때문이다. 따라서 인터페이스, 클래스, 메소드의 이름을 바꿀 수 없고, 코드의 다른 부분에서도 이용할 수 있도록 클래스에 메소드를 추가할 수도 없다.
•
기본적으로 API 호출의 설계를 개선하는 방법은 두 가지가 있다.
◦
API를 포장한다.
▪
이는, 가급적 API에 가깝게 모방한 인터페이스를 만들고 이 API의 래퍼를 작성한다.
▪
오류를 최소화하기 위해 메소드 시그니처를 유지할 수 있다.
▪
이 기법의 장점 중 하나는 최종적으로 API 코드에 의존하지 않아도 된다는 점이다.
•
래퍼를 사용하기 때문에 배포 코드에서는 API에 처리를 위임하고 테스트 코드에서는 가짜 객체를 사용할 수 있다.
◦
책임을 기반으로 추출한다.
▪
기능들을 책임으로 나눠, 객체지향적으로 개발을 시도한다.
▪
이는 클래스 간 조임 지점을 만들며 이 지점을 인터페이스화시켜 의존성을 분리할 수 있다.
•
API 포장과 책임 기반 추출 가운데 어떤 상황에 어떤 것을 사용해야 할까?
◦
API 포장은 다음과 같은 상황에 사용하면 좋다.
▪
API의 크기가 크지 않은 경우
▪
서드파티 라이브러리에 대한 의존 관계를 완전히 분리하고 싶은 경우
▪
현재 테스트 루틴이 없고 API를 통해 테스트할 수 없는 탓에 테스트 루틴을 작성할 수 없는 경우
◦
책임 기반 추출은 다음과 같은 상황에 사용하면 좋다.
▪
API가 복잡한 경우
▪
안전하게 메소드를 추출하는 도구를 갖고 있거나 수동으로 추출할 수 있다는 확신이 드는 경우
•
가급적 책임 기반 추출로 문제를 풀어내고 의존성을 약화시키는 것이 나아 보인다.
