public XxxService(final XxxDao xxxDao) {
  this.xxxDao = xxxDao;
}

XxxDao 를 한 번 상속한 테스트용 구현체를 넣은다.
> 이것을 `테스트 더블` (혹은 `대역`)이라고 한다
> 영화계 용어인데 스턴트란 뜻임 (배우의 `대역`)

아래와 같은 대역 클래스를 만들자

```java
class FakeXxxDao implements XxxDao {
}
```

> 예제 코드

```java
public class FakeMemberDao implements MemberDao {

    private final Map<String, Member> members = new HashMap<>();
    private AtomicInteger ids = new AtomicInteger();

    @Override
    public void save(final String id) {
        members.remove(id);
    }

    @Override
    public void save(final Member member) {
        int id = ids.incrementAndGet();
        members.put(member.getId(), member);
    }

    @Override
    public Member findById(final String id) {
        return members.get(id);
    }

    @Override
    public List<Member> findAll() {
        return new ArrayList<>(members.values());
    }
}
```

> 테스트 코드와 구현

요구사항이 바뀌면 테스트와 구현이 바뀌는 것은 맞다

그러나 요구사항이 바뀌지도 않았음에도 구현을 리펙터링하는 과정에 테스트 코드가 변경이 된다면,

테스트 코드의 in/out은 그대로인데 프로덕션 코드를 리펙터링 하는 과정에 테스트 코드가 깨지면,

테스트 코드에 대한 부정적인 인식이 생긴다

테스트 코드는 리펙터링을 함에 있어서 심리적 안정감이 들게 하는 보호 수단이 되어야만 한다

테스트 코드가 리펙터링함에 있어서의 걸림돌이 되어서는 안됀다

테스트 코드가 내부 구현을 모르게끔 테스트를 하려면 협력객체 (Dao)를 대역으로 바꿔치기한다

> Dao와 Service의 테스트 관심사

Dao : DB와 연결되어 커넥션 등의 테스트가 잘 되는지?
Service : Dao를 통해서 서비스 로직이 잘 되는지?

## 기타

> https://www.slipp.net/questions/276
> 포비의 jdbc driver 등록 추적

> Stubbing (찾아볼 키워드)