자바에서 코틀린으로

344

자바에서 코틀린으로

서드 중 단 하나만 기능을 구현하는 경우에도 다중 메서드 인터페이스를 사용하는 경우가 있었

다. 이로 인해 앞에서 설명했던 결합 문제가 발생한다. 그리고 목 (또는 더 엄밀히 말해 가짜 )

프레임워크는 실제로는 단 하나의 메서드만 호출되는 경우에도 더 넓은 인터페이스의 테스트

구현을 만들어야만 했다. 이런 가짜 구현은 여러분이 호출하기로 되어있지 않은 메서드를 호출

할 경우 (실행 시점에 ) 빨리 오류를 내며 끝나는데, 만약 이런 의존 관계를 함수 하나로 표현

한다면 아예 컴파일 시점에 이런 문제가 해결될 수 있었을 것이다.

코드 기반에 목

mock

프레임워크를 하나(더 일반적으로, 취향에 따라 두세 가지 목 프레임워크

를) 도입하고 나면, 이들이 사용하지 않는 메서드의 구현을 생성하거나 외부 시스템과의 상호

작용을 흉내내는 스텁을 생성하는 문제를 우리 대신 해결해 준다. 하지만, 목의 필요성을 없애

면 코드가 더 개선되는 게 일반적이다. 의존 관계를 함수 타입으로 표현하는 것이 한 가지 예이

고,

20

장에서 설명하는 것처럼 외부 시스템과의 상호 작용을 코드의 밖으로 옮기는 것이 또 다

른 예이다.

17

장에서는 테스트를 보다 함수형 형태로 리팩터링함으로써 목 사용을 줄이는 방

법을 살펴본다.

16.9

추적 가능성

의존 관계를 함수 타입으로 표현하는 데 따른 단점도 있다. 이 단점은 간접 계층을 추가할 때

흔히 발생하는 문제이기도 하다. 인텔리

J

를 사용해

EmailSystem

.

send

를 호출한 코드를 추적

하면,

EmailSystem ...