더북(TheBook)

테스트가 몇 개 없으면 큰 문제없지만, 일반적으로는 여러 공통 의존성을 가짜로 만들어야 하는 테스트가 수백 또는 수천 개 있을 수 있다. 예를 들어 API가 변경된 로거를 수정할 때 파일을 수백 개 수정해야 할 수도 있다.

이러한 상황을 막을 수 있는 방법으로 다음 두 가지가 있다.

제어할 수 없는 서드 파티 의존성을 코드에 직접 가져오지 말고, 항상 제어할 수 있는 중간 추상화를 사용해야 한다. 포트(Port)와 어댑터(Adapter) 아키텍처(헥사고날(Hexagonal) 아키텍처, 어니언(Onion) 아키텍처라고도 한다)가 좋은 예시다. 이러한 아키텍처를 사용하면 코드가 변하는 주기를 우리가 조절할 수 있기 때문에 테스트도 그만큼 영향을 덜 받게 되며, 내부 API를 가짜로 만드는 위험도 줄어들 수 있다. 외부 환경이 변하더라도 내부적으로 리팩터링을 할 수 있으며, 테스트는 이에 영향을 받지 않는다.

모듈 의존성 주입을 하지 말고 이 책에서 다루는 다른 의존성 주입 방식을 사용하는 것이 좋다. 함수의 매개변수를 사용하거나 부분 적용(커링)을 사용하는 방식이다. 다음 절에서 소개할 내용이지만 생성자(constructor)와 인터페이스(interface)를 사용하는 것도 하나의 방식이다. 이러한 방식을 사용하면 의존성을 직접 가져오는 것보다 더 다양한 선택지를 활용할 수 있다.

신간 소식 구독하기
뉴스레터에 가입하시고 이메일로 신간 소식을 받아 보세요.