테스트 대상이 환경이나, 외부 서버, 다른 클래스의 코드에 종속되고 영향을 받지 않도록 고립시킬 필요가 있다. ⇒ 테스트를 위한 대역을 사용

테스트 스텁

• MailSender 에는 이미 DummyMailSender 라는 테스트 스텁을 적용했다.
• 테스트 대역이 테스트 검증에도 참여할 수있도록 만든 MockMailSender 라는 목 오브젝트도 사용해봤다.

테스트를 위한 UserServiceImpl 고립

트랜잭션 코드를 독립시켰기 때문에 사용자 관리 로직을 담은 UserServiceImpl 은 PlatformTransactionManager 에 더이상 의존하지 않는다.

• UserServiceImpl 은 테스트가 진행될 때 사전에 테스트를 위해 준비된 동작만 하도록 만든 두 개의 목 오브젝트에만 의존한다.
  • 완벽하게 고립된 테스트 대상으로 만들 수 있다.

UserDao 객체

• 단지 테스트 대상의 코드가 정상적으로 수힝되도록 도와주는 스텁이 아니다.
• 부가적인 검증 기능까지 가진 목 오브젝트로 만들었다.
  • 고립된 환경에서 동작하는 upgradeLevels() 의 테스트 결과를 검증할 방법이 필요하기 때문

테스트 대상 메서드가 void 형인 경우

• UserServiceImpl 의 upgradeLevels() 메서드는 리턴값이 없는 void 형
• 메서드를 실행하고 결과를 받아 검증하는 것이 불가능하다.
  • DAO 를 통해 필요한 정보를 가져와 일정한 작업을 수행하고, 그 결과를 다시 DAO 에 반영한다.
• 코드 동작이 바르게 수행되었는지 확인하려면 결과가 남아있는 DB 를 직접 확인해야한다.
• 기존 테스트 코드
  • UserService 의 메서드를 실행시킨 후에 UserDao 를 이용해 DB 에 들어간 결과를 가져와 검증
  • 고립된 테스트 방식으로 만든 UserServiceImipl 은 기능이 수행되어도 DB 를 통해 결과가 남지 않는다.
  • upgradeLevels() 처럼 결과가 리턴되지 않는 경우는 더더욱 검증이 어렵다.

테스트 대상인 UserServiceImpl 과 그 협력 오브젝트인 UserDao 에게 어떤 요청을 했는지를 확인하는 작업이 필요하다.