UserService 의 경우를 생각하자.

• 구현 클래스들이 동작하기 위해 세가지 타입 의존 오브젝트가 필요

1. UserDao 타입 오브젝트를 통해 DB 와 데이터를 주고 받아야 한다.
2. MailSender 를 구현한 오브젝트를 이용해 메일을 발생해야 한다.
3. 트랜잭션 처리를 위해 PlatformTransactionManager 와 커뮤니케이션이 필요하다.

UserServiceTest

• 테스트 대상: UserService
  • 사용자 정보를 관리하는 비즈니스 로직의 구현 코드
  • 테스트 단위 → UserService 클래스

UserService 의 특징

• 세가지 의존관계를 갖는 오브젝트들이 테스트가 진행되는 동안 같이 실행된다.
  • UserDao, TransactionManager, MailSender…
• 의존 오브젝트들도 자신의 코드만 실행하고 마는 것이 아니다.

  • JDBC 를 이용해 UserDao를 구현한 UserDaoJdbc

    → DataSource 의 구현클래스와 DB 드라이버, DB 서버까지 네트워크 통신과 DB 서버 자체, 그 안에 정의된 테이블 모두에 의존한다.

  • 트랜잭션 매니저: DataSource 방식이라 데이터 소스 구현에만 의존

    • JTA 였다면 JTA 구현 오브젝트와 WAS 서버의 트랜잭션 서비스에까지 의존하고 있을 것

  • 메일도 메일 서버의 셋업 상태까지 모두 의존

• 보이는 것보다 훨씬 많은 오브젝트와 환경, 서비스, 서버, 네트워크까지 함께 테스트하게 되는 셈
  • 어느 하나 셋업이 안되거나 코드에 문제가 있을 시 UserService 에 대한 테스트는 실패한다.

의존 관계를 갖는 클래스에 대한 테스트

• 준비가 어렵고 환경이 조금이라도 달라지면 동일한 테스트 결과를 내지 못할 수 있다.
• 수행 속도가 느리고 그에 따라 테스트를 작성하고 실행하는 빈도가 점차 떨어질 것이다.
• 누군가가 의존 오브젝트 코드를 만져서 오류가 발생한다면 UserService 테스트는 실패하고 원인을 찾느라 불필요한 시간을 낭비해야 할 수 있다.