[spring] aop_목프레임워크_0

1.     Com.springsource.javax.activation : Spring java-mail

2.     Com.springsource.javax.mail : Spring java-mail

3.     Com.springsource.junit : junit

4.     Commons-logging : Spring-context가 사용

5.     Mail : java-mail

6.     Mockito : 목 프레임워크 중 Mockito

7.     Mysql-connector : Mysql JDBC

8.     Org.springframework.context.support : Spring java-mail

9.     Spring-aop : 스프링 기능 자체의 aop

10.   Spring-bean : 스프링 빈을 활용하는 경우 필요. 스프링의 XML 설정파일과 자바 애노테이션을 파싱 하는데 필요한 클래스 포함

11.   Spring-context : 스프링 코어를 확장한 많은 클래스가 들어 있는데 모든 클래스는 EJB, JNDI(Java Naming Directory Interface), JMX용 클래스와 연동하는데 applicationcontext기능을 사용해야 하며 스프링 리모팅 클래스, 동적 스크립팅 언어(제이루비, 그루비등)와 연동하는 클래스, 빈 유효성검증(JSR-303) API, 스케줄링을 하는 클래스도 포함되어 있다.

12.   Spring-core : 모든 스프링 모듈에서 필요한 모듈. 다른 스프링 모듈에서 사용하는 공통 클래스가 포함됨.

13.   Spring-dao : EmpltyResultDataAccessException 등 사용을 위한 jar

14.   Spring-expression : 스프링 표현언어(SpEL) 지원 클래스 포함.

15.   Spring-jdbc : 스프링이 지원하는 jdbc.

16.   Spring-test.jar

-       @RunWith : Junit 프레임워크의 테스트 실행방법을 확장시 사용.

-       SpringJUnit4ClassRunner : 어플리케이션컨텍스트를 만들고 관리하는 확장 클래스

-       @ContextConfiguration(경로) : 자동으로 만들어줄 어플리케이션 컨텍스트 설정파일

17.   Spring-tx : DuplicateKeyException.class 파일 존재 및 스프링 트랜잭션

 

Level이 할일 다음레벨을 알고 레벨 객체에 세팅하는 일을 위임

 

*  단위테스트마다 스텁이나 목 오브젝트의 사용이 필수인데 이를 만드는 것은 짐이다. 매번 귀찮은 일이 아닐 수 없다.

>  사용하기 편리하고 직관적인 Mockito 프레임워크를 사용할 것이다.

 

 

User의 할일 위임 다음 레벨값을 레벨에게 얻어와 User객체에 셋팅

 

 

Hibernate, JDO, JPA, JDBC 등의 DataAccess API의 여러 종류를 위한 인터페이스

 

JDBC 구현

 

 

 

 

메일을 테스트시에도 계속 보내면 과부하가 걸리므로 Stub 작성

 

Hibernate, JDBC, JDO, JPA 등 트랜잭션 방식이 다르므로 서비스 인터페이스

 

 

 

비즈니스 로직 impl, 어떤 트랜잭션 방식이어도 비즈니스 로직은 변하지 않음

 

 

JDBC 트랜잭션 방식일 때를 위한 구현체. 비즈니스 로직은 그대로 트랜잭션 기능만 둠.

 

 

26. Mockito와 같은 목 프레임워크는 대부분 목 클래스를 일일이 준비할 필요없이 스태닉 메소드 한번으로 만들어 지므로 미리 static import를 사용해 로컬 메소드처럼 호출하게 하면 편리하다.

50~. DI 즉 통합테스트가 아닌 단위테스트를 위해 MockUserDao를 사용. New 를 통해 외부 환경에 주입된 빈이 아닌 독립된 테스트를 위해

 

 

이런식으로 MockObject를 생성해도 되지만 상당히 번거로움

 

 

 

 

 

161. new : 단위테스트(고립된 테스트를 위함)

162. mock(인터페이스) : 메소드 호출만으로 다이내믹하게 특정 인터페이스를 구현한 테스트용 목 오브젝트가 생성됨. 아무런 기능이 없음.

> 규칙1) 인터페이스를 통해 목 오브젝트를 만든다.

163. mockUserDao.getAll() 이 호출됐을 때(when) users를 리턴해줘(thenReturn)

> 즉, getAll() 메소드가 호출되면 users가 리턴될 것이다.

> 규칙2) 목 오브젝트가 리턴할 값이 있으면 이를 지정한다.

164. 규칙3) 테스트 대상 오브젝트에 DI해서 목 오브젝트가 테스트 중 사용되도록 한다.

170. verify(확인하라) mockUserDao의 update 메소드가 time(2)(2번 호출됐는지), any(User) User 타입의 오브젝트를 파라미터로 받으면서(any : 어떤 파라미터든지 관계없이)

> 규칙4) 테스트 대상 오브젝트를 사용한 후에 목 오브젝트의 특정 메소드가 호출됐는지, 어떤 값을 가지고 몇번 호출 됐는지를 검증

172. users.get(1)을 파라미터로 update()가 호출된 적이 있는지를 확인. Update()가 호출된 적이 없거나 파라미터가 users.get(1)이 아니었다면 테스트 실패

177. org.mockito.ArgumentCaptor : 파라미터를 정밀하게 검사하기 위해 캡처할 수도 있다(capture()). 실제 MailSender 목 오브젝트에 전달된 파라미터를 가져와 내용을 검증. 파라미터 직접 비교하기보다는 파라미터(인자값)의 내부 정보를 확인해야 하는 경우에 유용하다.