고립된 단위 테스트
단위 테스트는 당연히 작은 단위어야 한다.
쉽고, 빠르고, 명확하기 때문이다.
복잡한 의존관계 속의 테스트
UserService 테스트를 위해 필요한 구조
- DB와 데이터를 주고 받기 위한 UserDaoJdbc
- 트랜잭션 처리를 위한 Transaction Manager
- 메일 전송을 위한 MailSender
문제점
간단한 UserService 테스트를 위해서는 DB, Transaction 등 의존 관계를 명시해줘야 한다.
테스트하기 복잡하고, 환경에 영향을 받는다.
테스트 대상 오브젝트 고립시키기
단위테스트 vs 통합테스트
둘 중에 어떤걸 써야할까?
- 항상 단위 테스트를 먼저 고려한다
- 외부 리스소를 사용해야 하는경우만 통합 테스트. 외부와의 의존관계는 모두 차단하고 필요에 따라 목 오브젝트 등의 테스트 대역을 이용
스프링이 권장하는 유연한 코드를 만들다보면 테스트도 그만큼 쉬워지고, 리팩토링도 쉽게 접근할 수 있게 된다.
목 프레임워크
Mockito 프레임워크
목 클래스를 일일이 준비해둘 필요가 없도록 도와주는 목 프레임워크이다.
UserDao mockUserDao = mock(UserDao.class);
when(mockUserDao.getAll()).thenReturn(this.users);
다음은 updates() 호출이 있었는지를 검증하는 부분이다.
verify(mockUserDao, times(2).update(any(User.class));
사용방법
1. 인터페이스를 이용해 목오브젝트 생성
2. 목 오브젝트가 리턴할 값이 있으면 이를 지정해 준다.
3. 테스트 대상 오브젝트에 DI해서 목 오브젝트가 테스트 중에 사용되도록 만든다.
4. 진짜 테스트
'Back-End > 토비의 스프링3' 카테고리의 다른 글
토비의 스프링 7장(1) - SQL과 DAO의 분리 (0) | 2018.11.15 |
---|---|
토비의 스프링 6장(3) - 다이나믹 프록시와 팩토리 빈 (0) | 2018.11.06 |
토비의 스프링 6장(1) - AOP 트랜잭션 코드의 분리 (0) | 2018.10.31 |
토비의 스프링 - 4장. 예외 (0) | 2018.10.20 |
5-4장. 메일 서비스 추상화 (0) | 2018.10.08 |