🌈 Chapter 8: 서드 파티 코드를 기반으로 한 개발

📚 소유한 타입에 대해서만 목 객체를 적용하라

🎈 변경할 수 없는 타입에 대해서는 목 객체를 적용하지 말라

• 서드 파티 코드를 사용할 때 해당 코드의 작동 원리를 깊이 있게 이해하지 않을 때가 있다. 서드 파티 코드의 문서를 읽을 수는 있지만, 문서도 불완전하거나 올바르지 않을 때가 있다. 그러므로 추상화 요소가 어떻게 동작해야 할지 알고 있더라도 서드 파티 코드로 테스트하기 전까지는 실제로 그렇게 동작할지 알 수 없다.
• 아울러 서드 파티 코드 변경은 내키지 않는 일이다.
• 서드 파티 타입을 호출하는 객체를 대상으로 단위 테스트를 수행할 때 서드 파티 타입의 목 구현을 제공하더라도 쓰임이 제한적이라는 의미다. 시험할 필요가 있는 기능에 대해 코드를 올바른 상태에 두려면 외부 라이브러리에 대해 목 객체를 적용하는 테스트가 복잡해진다.
• 또 다른 위험 요소는 스텁이나 목 객체의 대상이 되는 행위가 외부 라이브러리에서 실제로 수행할 행위와 일치한다는 점을 보장해야 한다는 것이다. 이렇게 하는 것이 얼마나 어려운지는 라이브러리의 품질에 달렸다.

🎈 어댑터 계층을 작성하라

• 우리는 TDD를 이용해 객체에서 필요로 하는 서비스에 대한 인터페이스를 설계할 것이다. 이때 인터페이스는 우리가 작성한 객체의 관점에서 정의되지, 외부 라이브러리 관점에서 정의되지는 않을 것이다.
• 우리는 이 인터페이스를 구현하기 위해 서드 파티 API를 쓰는 어댑터 객체 계층을 작성한다. 이 계층은 되도록 앏게 유지하는데, 잠재적으로 불안정하고 테스트하기 어려운 코드 양을 줄이기 위해서다.
• 아울러 서드 파티 API의 작동 방식에 대해 얼마나 이해하고 있는지 확인하고자 집중적인 통합 테스트로 어댑터를 테스트할 것이다. 이러한 접근법을 꾸준히 따르다 보면 애플리케이션과 해당 애플리케이션 관점 밖에 존재하는 셰계와의 관계를 규정하는 인터페이스가 만들어지고, 저수준의 기술적인 개념이 애플리케이션 도메인 모델로 스며들지 않게 할 수 있다.
• 이러한 패턴은 값 객체에는 적용되지 않는다. 당연히 값 객체에 대해서는 목 객체를 적용할 필요가 없기 때문이다.

📚 통합 테스트에서 애플리케이션 객체에 목 객체를 적용하라

• 어댑터 객체는 수동적이여서 코드에서 호출할 때만 반응한다. 이따금 어댑터 객체가 애플리케이션의 객체로 콜백해야만 할 때가 있다.
• 이 경우 우리는 서드 파티 코드와 통합되는 객체를 테스트할 때 목 객체를 꼭 이용한다. 그렇지만 애플리케이션에서 정의한 콜백 인터페이스에 목 객체를 적용하기만 하는데, 이렇게 하는 이유는 도메인 사이에서 이벤트를 올바르게 번역하는지 검증하기 위해서다.