#6. AOP

6단원 공부하기 전에

---

AOP는 스프링을 공부하면서 IoC/DI, 서비스 추상화와 함께 나오는 스프링 3대 기술 중의 하나다. 항상 뒤에 나오고 가장 어려운 내용이라 제대로 공부를 하지 못했다. AOP를 제대로 사용하려면 스프링이 도입한 이유와 장점이 무엇인지 이해해야 한다. 

 AOP의 적용 대상은 선언적 트랜잭션 기능(???)이다.  AOP를 통해서 5단원에서 공부했던 코드를 더욱 더 깔끔한 방식으로 바꿀수 있다고 하네.....

6.1 트랜잭션 코드의 분리

---

 5단원에서 서비스 추상화 기법을 통해 트랜잭션 기술에 독립적으로 만들어줬지만, 아직 서비스 코드에 쓸데없이 긴 트랜잭션 코드가 보인다.  그렇다고 이를 제거하기에는 트랜잭션 경계가 비즈니스 로직의 전후에 설정돼야 하는 것이 분명하다.

 1) 트랜잭션 경계 설정 부분을 메소드 분리해보자

- 트랜잭션 경계 코드와 비즈니스 로직이 섞여 있다!

 2) DI를 이용한 클래스의 분리

- 

6.2 고립된 단위 테스트

---

 (앞부분 날아감 ㅠㅠ)

• 단위 테스트 vs 통합 테스트

1. 항상 단위 테스트를 우선시 한다.

2. 하나의 클래스나 긴밀도가 높은 클래스들을 모아서 외부와의 의존관계를 모두 차단하고 스텁이나 목 오브젝트를 이용하여 테스트를 만든다.
   

3. DAO와 같이 DB를 통해 로직을 수행하는 것은 어쩔 수 없이 통합 테스트로 작성한다. 하지만 DB에 있는 데이터들을 관리하는 의미에서는 하나의 단위 테스트이다. 이를 충분히 검증해 놓으면, 비즈니스 로직에서는 목 오브젝트를 이용해서 테스트를 하면 된다.

4. 단위 테스트를 만들기에 너무 복잡한 코드는 처음부터 통합 테스트를 고려한다. 하지만, 코드 중에서 가능한 부분은 최대한 단위테스트를 작성하는 것이 유지보수에 용이하다.
   
   

• 위의 가이드나 테스트 코드 만드는 작업을 생각하면 벌써 지친다. 하지만 왜 테스트 코드를 만들어야 할까?
  

1. 리팩토링 작업시에 확인하기 용이

2. 단위 테스트를 고려하다 보면 코드 자체가 깔끔해 짐
   
   
   

• 테스트 코드를 위한 데이터를 만들어야 하는데 너무 귀찮다..... 목 프레임워크

• 기존의 불편함

1. MockUserDao를 보면 UserDao 인터페이스의 모든 함수를 쓰지 않음에도 전체다 구현해줘야 한다.

2. 메소드 별로 다른 검증 기능이 필요하면, MockUserDao 같은 목 클래스가 계속 생겨난다.

• Mockito framework

• s