토비의스프링3/밑줄긋기 - Revision history

imported>rabierre at 07:11, 30 July 2011

2011-07-30T07:11:05Z

← Older revision		Revision as of 07:11, 30 July 2011
Line 67:		Line 67:
	* p.335		* p.335
	** 이 정도 코드라면 한 번 살펴보는 것 만으로도 오류가 있는지 쉽게 찾아낼 자신이 있는 개발자도 있겠지만, 정말 뛰어난 개발자라면 아무리 간단해 보여도 실수할 수 있음을 알고 있기 때문에 테스트를 만들어서 직접 동작하는 모습을 확인해보려고 할 것이다.		** 이 정도 코드라면 한 번 살펴보는 것 만으로도 오류가 있는지 쉽게 찾아낼 자신이 있는 개발자도 있겠지만, 정말 뛰어난 개발자라면 아무리 간단해 보여도 실수할 수 있음을 알고 있기 때문에 테스트를 만들어서 직접 동작하는 모습을 확인해보려고 할 것이다.
			** 이정도~ 부분을 읽고 자신있어한 내가 부끄럽다.. 헐리우드에 가서 jesus=heaven no jesus=hell 판들고 행진하는 사람들처럼.. - [[서지혜]]
	* p.339		* p.339
	** 코드가 깔끔해 보이지 안는 이유는 이렇게 성격이 다른 여러 가지 로직이 한데 섞여있기 때문이다.		** 코드가 깔끔해 보이지 안는 이유는 이렇게 성격이 다른 여러 가지 로직이 한데 섞여있기 때문이다.

imported>rabierre at 07:08, 30 July 2011

2011-07-30T07:08:14Z

← Older revision		Revision as of 07:08, 30 July 2011
Line 115:		Line 115:
	** 서비스 추상화란 이렇게 원활한 테스트만을 위해서도 충분히 가치가 있다. 기술이나 환경이 바뀔 가능성이 있음에도, JavaMail처럼 확장이 불가능하게 설계해놓은 API를 사용해야 하는 경우라면 추상화 계층의 도입을 적극 고려해볼 필요가 있다. 특별히 외부의 리소스와 연동하는 대부분 작업은 추상화의 대상이 될 수 있다.		** 서비스 추상화란 이렇게 원활한 테스트만을 위해서도 충분히 가치가 있다. 기술이나 환경이 바뀔 가능성이 있음에도, JavaMail처럼 확장이 불가능하게 설계해놓은 API를 사용해야 하는 경우라면 추상화 계층의 도입을 적극 고려해볼 필요가 있다. 특별히 외부의 리소스와 연동하는 대부분 작업은 추상화의 대상이 될 수 있다.
	* p.395		* p.395
	** 테스트 환경을 만들어주기 위해, 테스트 대상이 되는 오브젝트의 기능에만 충실하게 수행하면서 빠르게, 자주 테스트를 실행할 수 있도록 사용하는 이런 오브젝트를 통틀어서 테스트 대역(test double)이라고 부른다.		** 테스트 환경을 만들어주기 위해, 테스트 대상이 되는 오브젝트의 기능에만 충실하게 수행하면서 빠르게, 자주 테스트를 실행할 수 있도록 사용하는 이런 오브젝트를 통틀어서 테스트 대역(test double)이라고 부른다.
			** SE에서는 테스트 대역이 아니라 stub이라고 했는데 여기에서는 stub 오브젝트와 mock 오브젝트로 또 나눠진다. - [[서지혜]]
	* p.396		* p.396
	** 목 오브젝트는 스텁처럼 테스트 오브젝트가 정상적으로 실행되도록 도와주면서, 테스트 오브젝트와 자신의 사이에서 일어나는 커뮤니케이션 내용을 저장해뒀다가 테스트 결과를 검증하는 데 활용할 수 있게 해준다.		** 목 오브젝트는 스텁처럼 테스트 오브젝트가 정상적으로 실행되도록 도와주면서, 테스트 오브젝트와 자신의 사이에서 일어나는 커뮤니케이션 내용을 저장해뒀다가 테스트 결과를 검증하는 데 활용할 수 있게 해준다.

imported>rabierre at 07:06, 30 July 2011

2011-07-30T07:06:57Z

← Older revision	Revision as of 07:06, 30 July 2011
(No difference)

imported>rabierre at 07:06, 30 July 2011

2011-07-30T07:06:47Z

← Older revision		Revision as of 07:06, 30 July 2011
Line 114:		Line 114:
	* p.392		* p.392
	** 서비스 추상화란 이렇게 원활한 테스트만을 위해서도 충분히 가치가 있다. 기술이나 환경이 바뀔 가능성이 있음에도, JavaMail처럼 확장이 불가능하게 설계해놓은 API를 사용해야 하는 경우라면 추상화 계층의 도입을 적극 고려해볼 필요가 있다. 특별히 외부의 리소스와 연동하는 대부분 작업은 추상화의 대상이 될 수 있다.		** 서비스 추상화란 이렇게 원활한 테스트만을 위해서도 충분히 가치가 있다. 기술이나 환경이 바뀔 가능성이 있음에도, JavaMail처럼 확장이 불가능하게 설계해놓은 API를 사용해야 하는 경우라면 추상화 계층의 도입을 적극 고려해볼 필요가 있다. 특별히 외부의 리소스와 연동하는 대부분 작업은 추상화의 대상이 될 수 있다.
			* p.395
			** 테스트 환경을 만들어주기 위해, 테스트 대상이 되는 오브젝트의 기능에만 충실하게 수행하면서 빠르게, 자주 테스트를 실행할 수 있도록 사용하는 이런 오브젝트를 통틀어서 테스트 대역(test double)이라고 부른다.
	* p.396		* p.396
	** 목 오브젝트는 스텁처럼 테스트 오브젝트가 정상적으로 실행되도록 도와주면서, 테스트 오브젝트와 자신의 사이에서 일어나는 커뮤니케이션 내용을 저장해뒀다가 테스트 결과를 검증하는 데 활용할 수 있게 해준다.		** 목 오브젝트는 스텁처럼 테스트 오브젝트가 정상적으로 실행되도록 도와주면서, 테스트 오브젝트와 자신의 사이에서 일어나는 커뮤니케이션 내용을 저장해뒀다가 테스트 결과를 검증하는 데 활용할 수 있게 해준다.

imported>rabierre at 07:06, 30 July 2011

2011-07-30T07:06:25Z

← Older revision		Revision as of 07:06, 30 July 2011
Line 109:		Line 109:
	** 그런데, 과연 테스트를 하면서 매번 메일이 발송되는 것이 바람직한가? 대개는 바람직하지 못하다.		** 그런데, 과연 테스트를 하면서 매번 메일이 발송되는 것이 바람직한가? 대개는 바람직하지 못하다.
	** 여기서 지적하지 않았다면 그 부분에 대해 딱히 문제라고 생각하지 않았을 것 같다. - [[김수경]]		** 여기서 지적하지 않았다면 그 부분에 대해 딱히 문제라고 생각하지 않았을 것 같다. - [[김수경]]
			** 나도 테스트 켜놓고 놀러갔을 거같다 - [[서지혜]]
			* p.391
			** 서비스 추상화에는 기능은 유사하나 사용 방법이 다른 로우레벨의 다양한 기술에 대해 추상 인터페이스와 일관성 있는 접근 방법을 제공해주는 것을 말한다. 반면에 테스트를 어렵게 만드는 건전하지 않은 방식으로 설계된 API를 사용할 때도 유용하게 쓰일 수 있다.
	* p.392		* p.392
	** 서비스 추상화란 이렇게 원활한 테스트만을 위해서도 충분히 가치가 있다. 기술이나 환경이 바뀔 가능성이 있음에도, JavaMail처럼 확장이 불가능하게 설계해놓은 API를 사용해야 하는 경우라면 추상화 계층의 도입을 적극 고려해볼 필요가 있다. 특별히 외부의 리소스와 연동하는 대부분 작업은 추상화의 대상이 될 수 있다.		** 서비스 추상화란 이렇게 원활한 테스트만을 위해서도 충분히 가치가 있다. 기술이나 환경이 바뀔 가능성이 있음에도, JavaMail처럼 확장이 불가능하게 설계해놓은 API를 사용해야 하는 경우라면 추상화 계층의 도입을 적극 고려해볼 필요가 있다. 특별히 외부의 리소스와 연동하는 대부분 작업은 추상화의 대상이 될 수 있다.
Line 116:		Line 119:
	** 목 오브젝트를 이용한 테스트라는 게, 작성하기는 간단하면서도 기능을 상당히 막강하다는 사실을 알 수 있을 것이다. 보통의 테스트 방법으로는 검증하기가 매우 까다로운 테스트 대상 오브젝트의 내부에서 일어나는 일이나 다른 오브젝트 사이에서 주고받는 정보까지 검증하는 일이 손쉽기 때문이다.		** 목 오브젝트를 이용한 테스트라는 게, 작성하기는 간단하면서도 기능을 상당히 막강하다는 사실을 알 수 있을 것이다. 보통의 테스트 방법으로는 검증하기가 매우 까다로운 테스트 대상 오브젝트의 내부에서 일어나는 일이나 다른 오브젝트 사이에서 주고받는 정보까지 검증하는 일이 손쉽기 때문이다.
	** 목 오브젝트를 이용한 테스트가 작성하기 간단하…지 않았었는데. - [[김수경]]		** 목 오브젝트를 이용한 테스트가 작성하기 간단하…지 않았었는데. - [[김수경]]
			** 이지목같은거 안써도 목 오브젝트를 만들어 쓸 수 있구나.. - [[서지혜]]
	== 선택 ==		== 선택 ==
	----		----
	[[토비의스프링3]], [[Spring/탐험스터디]]		[[토비의스프링3]], [[Spring/탐험스터디]]

imported>linflus at 07:04, 30 July 2011

2011-07-30T07:04:37Z

← Older revision	Revision as of 07:04, 30 July 2011
(No difference)

imported>linflus at 07:03, 30 July 2011

2011-07-30T07:03:50Z

← Older revision		Revision as of 07:03, 30 July 2011
Line 116:		Line 116:
	** 목 오브젝트를 이용한 테스트라는 게, 작성하기는 간단하면서도 기능을 상당히 막강하다는 사실을 알 수 있을 것이다. 보통의 테스트 방법으로는 검증하기가 매우 까다로운 테스트 대상 오브젝트의 내부에서 일어나는 일이나 다른 오브젝트 사이에서 주고받는 정보까지 검증하는 일이 손쉽기 때문이다.		** 목 오브젝트를 이용한 테스트라는 게, 작성하기는 간단하면서도 기능을 상당히 막강하다는 사실을 알 수 있을 것이다. 보통의 테스트 방법으로는 검증하기가 매우 까다로운 테스트 대상 오브젝트의 내부에서 일어나는 일이나 다른 오브젝트 사이에서 주고받는 정보까지 검증하는 일이 손쉽기 때문이다.
	** 목 오브젝트를 이용한 테스트가 작성하기 간단하…지 않았었는데. - [[김수경]]		** 목 오브젝트를 이용한 테스트가 작성하기 간단하…지 않았었는데. - [[김수경]]
			== 선택 ==
	----		----
	[[토비의스프링3]], [[Spring/탐험스터디]]		[[토비의스프링3]], [[Spring/탐험스터디]]

imported>linflus at 07:03, 30 July 2011

2011-07-30T07:03:30Z

← Older revision		Revision as of 07:03, 30 July 2011
Line 21:		Line 21:
	** 변화의 성격이 다르다는 건 변화의 이유와 시기, 주기 등이 다르다는 뜻이다.		** 변화의 성격이 다르다는 건 변화의 이유와 시기, 주기 등이 다르다는 뜻이다.
	=== 테스트 ===		=== 테스트 ===
	== 템플릿 ==		=== 템플릿 ===
	* p.211		* p.211
	** 템플릿이란 이렇게 바뀌는 성질이 다른 코드 중에서 변경이 거의 일어나지 않으며 일정한 패턴으로 유지되는 특성을 가진 부분을 자유롭게 변경되는 성질을 가진 부분으로부터 독립시켜서 효과적으로 활용할 수 있도록 하는 방법이다.		** 템플릿이란 이렇게 바뀌는 성질이 다른 코드 중에서 변경이 거의 일어나지 않으며 일정한 패턴으로 유지되는 특성을 가진 부분을 자유롭게 변경되는 성질을 가진 부분으로부터 독립시켜서 효과적으로 활용할 수 있도록 하는 방법이다.
Line 37:		Line 37:
	** 템플릿과 콜백을 찾아낼 때는, 변하는 코드의 경계를 찾고 그 경계를 사이에 두고 주고받는 일정한 정보가 있는지 확인하면 된다고 했다.		** 템플릿과 콜백을 찾아낼 때는, 변하는 코드의 경계를 찾고 그 경계를 사이에 두고 주고받는 일정한 정보가 있는지 확인하면 된다고 했다.
	* hamcrest.CoreMatchers에 대해서 : CoreMatcher로 테스트 코드를 만들 때 null 값은 비교나 not을 사용하는 것이 불가능합니다(ex. assertThat(tempObject, is(null)); -> 에러). 이건 null이 값이 아니기 때문인데, CoreMatcher에서 null 값을 쓸 때는 org.hamcrest.CoreMatchers의 notNullValue()와 nullValue()를 사용하시면 되겠습니다. http://jmock.org/javadoc/2.5.1/org/hamcrest/CoreMatchers.html		* hamcrest.CoreMatchers에 대해서 : CoreMatcher로 테스트 코드를 만들 때 null 값은 비교나 not을 사용하는 것이 불가능합니다(ex. assertThat(tempObject, is(null)); -> 에러). 이건 null이 값이 아니기 때문인데, CoreMatcher에서 null 값을 쓸 때는 org.hamcrest.CoreMatchers의 notNullValue()와 nullValue()를 사용하시면 되겠습니다. http://jmock.org/javadoc/2.5.1/org/hamcrest/CoreMatchers.html
	== 예외 ==		=== 예외 ===
	* p.283		* p.283
	** 예외는 처리돼야 한다.		** 예외는 처리돼야 한다.
Line 47:		Line 47:
	* p.317		* p.317
	** 애플리케이션의 로직을 담기 위한 예외는 체크 예외로 만든다.		** 애플리케이션의 로직을 담기 위한 예외는 체크 예외로 만든다.
	== 서비스 추상화 ==		=== 서비스 추상화 ===
	=== 사용자 레벨 관리 기능 추가 ===		==== 사용자 레벨 관리 기능 추가 ====
	* p.320		* p.320
	** 의미 없는 숫자를 프로퍼티에 사용하면 타입이 안전하지 않아서 위험할 수 있다.		** 의미 없는 숫자를 프로퍼티에 사용하면 타입이 안전하지 않아서 위험할 수 있다.
Line 76:		Line 76:
	* p.349		* p.349
	** 한 가지 변경 이유가 발생했을 때 여러 군데를 고치게 만든다면 중복이다.		** 한 가지 변경 이유가 발생했을 때 여러 군데를 고치게 만든다면 중복이다.
	=== 트랜잭션 서비스 추상화 ===		==== 트랜잭션 서비스 추상화 ====
	* p.351		* p.351
	** 게다가 테스트의 기본은 자동화된 테스트여야 하니 사람이 간섭하는 것은 좋은 생각이 아니다.		** 게다가 테스트의 기본은 자동화된 테스트여야 하니 사람이 간섭하는 것은 좋은 생각이 아니다.
Line 94:		Line 94:
	* p.374		* p.374
	** 어떤 클래스든 스프링의 빈으로 등록할 때 먼저 검토해야 할 것은 싱글톤으로 만들어져 여러 스레드에서 동시에 사용해도 괜찮은가 하는 점이다. 상태를 갖고 있고, 멀티스레드 환경에서 안전하지 않은 클래스를 빈으로 무작정 등록하면 심각한 문제가 발생하기 때문이다.		** 어떤 클래스든 스프링의 빈으로 등록할 때 먼저 검토해야 할 것은 싱글톤으로 만들어져 여러 스레드에서 동시에 사용해도 괜찮은가 하는 점이다. 상태를 갖고 있고, 멀티스레드 환경에서 안전하지 않은 클래스를 빈으로 무작정 등록하면 심각한 문제가 발생하기 때문이다.
	=== 서비스 추상화와 단일 책임 원칙 ===		==== 서비스 추상화와 단일 책임 원칙 ====
	* p.377		* p.377
	** 이렇게 기술과 서비스에 대한 추상화 기법을 이요하면 특정 기술환경에 종속되지 않는 포터블한 코드를 만들 수 있다.		** 이렇게 기술과 서비스에 대한 추상화 기법을 이요하면 특정 기술환경에 종속되지 않는 포터블한 코드를 만들 수 있다.
Line 105:		Line 105:
	** 패턴이나 설계 원칙을 공부하는 이유는 폼나는 용어를 외우고 기계적인 지식을 습득하면 저절로 깔끔하고 유연한 코드가 나오기 때문이 아니다. 좋은 코드를 만들기 위한 개발자 스스로의 노력과 고민이 있을 때 도움을 주기 때문이다.		** 패턴이나 설계 원칙을 공부하는 이유는 폼나는 용어를 외우고 기계적인 지식을 습득하면 저절로 깔끔하고 유연한 코드가 나오기 때문이 아니다. 좋은 코드를 만들기 위한 개발자 스스로의 노력과 고민이 있을 때 도움을 주기 때문이다.
	** 스프링을 DI 프레임워크라고 부르는 이유는 외부 설정정보를 통한 런타임 오브젝트 DI라는 단순한 기능을 제공하기 때문이 아니다. 오히려 스프링이 DI에 담긴 원칙과 이를 응용하는 프로그래밍 모델을 자바 엔터프라이즈 기술의 많은 문제를 해결하는 데 적극적으로 활용하고 있기 때문이다. 또, 스프링과 마찬가지로 스프링을 사용하는 개발자가 만드는 애플리케이션 코드 또한 이런 DI를 활용해서 깔끔하고 유연한 코드와 설계를 만들어낼 수 있도록 지원하고 지지해주기 때문이다.		** 스프링을 DI 프레임워크라고 부르는 이유는 외부 설정정보를 통한 런타임 오브젝트 DI라는 단순한 기능을 제공하기 때문이 아니다. 오히려 스프링이 DI에 담긴 원칙과 이를 응용하는 프로그래밍 모델을 자바 엔터프라이즈 기술의 많은 문제를 해결하는 데 적극적으로 활용하고 있기 때문이다. 또, 스프링과 마찬가지로 스프링을 사용하는 개발자가 만드는 애플리케이션 코드 또한 이런 DI를 활용해서 깔끔하고 유연한 코드와 설계를 만들어낼 수 있도록 지원하고 지지해주기 때문이다.
	=== 메일 서비스 추상화 ===		==== 메일 서비스 추상화 ====
	* p.384		* p.384
	** 그런데, 과연 테스트를 하면서 매번 메일이 발송되는 것이 바람직한가? 대개는 바람직하지 못하다.		** 그런데, 과연 테스트를 하면서 매번 메일이 발송되는 것이 바람직한가? 대개는 바람직하지 못하다.

imported>linflus at 07:02, 30 July 2011

2011-07-30T07:02:15Z

← Older revision		Revision as of 07:02, 30 July 2011
Line 48:		Line 48:
	** 애플리케이션의 로직을 담기 위한 예외는 체크 예외로 만든다.		** 애플리케이션의 로직을 담기 위한 예외는 체크 예외로 만든다.
	== 서비스 추상화 ==		== 서비스 추상화 ==
			=== 사용자 레벨 관리 기능 추가 ===
	* p.320		* p.320
	** 의미 없는 숫자를 프로퍼티에 사용하면 타입이 안전하지 않아서 위험할 수 있다.		** 의미 없는 숫자를 프로퍼티에 사용하면 타입이 안전하지 않아서 위험할 수 있다.
Line 75:		Line 76:
	* p.349		* p.349
	** 한 가지 변경 이유가 발생했을 때 여러 군데를 고치게 만든다면 중복이다.		** 한 가지 변경 이유가 발생했을 때 여러 군데를 고치게 만든다면 중복이다.
			=== 트랜잭션 서비스 추상화 ===
	* p.351		* p.351
	** 게다가 테스트의 기본은 자동화된 테스트여야 하니 사람이 간섭하는 것은 좋은 생각이 아니다.		** 게다가 테스트의 기본은 자동화된 테스트여야 하니 사람이 간섭하는 것은 좋은 생각이 아니다.
Line 92:		Line 94:
	* p.374		* p.374
	** 어떤 클래스든 스프링의 빈으로 등록할 때 먼저 검토해야 할 것은 싱글톤으로 만들어져 여러 스레드에서 동시에 사용해도 괜찮은가 하는 점이다. 상태를 갖고 있고, 멀티스레드 환경에서 안전하지 않은 클래스를 빈으로 무작정 등록하면 심각한 문제가 발생하기 때문이다.		** 어떤 클래스든 스프링의 빈으로 등록할 때 먼저 검토해야 할 것은 싱글톤으로 만들어져 여러 스레드에서 동시에 사용해도 괜찮은가 하는 점이다. 상태를 갖고 있고, 멀티스레드 환경에서 안전하지 않은 클래스를 빈으로 무작정 등록하면 심각한 문제가 발생하기 때문이다.
			=== 서비스 추상화와 단일 책임 원칙 ===
	* p.377		* p.377
	** 이렇게 기술과 서비스에 대한 추상화 기법을 이요하면 특정 기술환경에 종속되지 않는 포터블한 코드를 만들 수 있다.		** 이렇게 기술과 서비스에 대한 추상화 기법을 이요하면 특정 기술환경에 종속되지 않는 포터블한 코드를 만들 수 있다.
Line 102:		Line 105:
	** 패턴이나 설계 원칙을 공부하는 이유는 폼나는 용어를 외우고 기계적인 지식을 습득하면 저절로 깔끔하고 유연한 코드가 나오기 때문이 아니다. 좋은 코드를 만들기 위한 개발자 스스로의 노력과 고민이 있을 때 도움을 주기 때문이다.		** 패턴이나 설계 원칙을 공부하는 이유는 폼나는 용어를 외우고 기계적인 지식을 습득하면 저절로 깔끔하고 유연한 코드가 나오기 때문이 아니다. 좋은 코드를 만들기 위한 개발자 스스로의 노력과 고민이 있을 때 도움을 주기 때문이다.
	** 스프링을 DI 프레임워크라고 부르는 이유는 외부 설정정보를 통한 런타임 오브젝트 DI라는 단순한 기능을 제공하기 때문이 아니다. 오히려 스프링이 DI에 담긴 원칙과 이를 응용하는 프로그래밍 모델을 자바 엔터프라이즈 기술의 많은 문제를 해결하는 데 적극적으로 활용하고 있기 때문이다. 또, 스프링과 마찬가지로 스프링을 사용하는 개발자가 만드는 애플리케이션 코드 또한 이런 DI를 활용해서 깔끔하고 유연한 코드와 설계를 만들어낼 수 있도록 지원하고 지지해주기 때문이다.		** 스프링을 DI 프레임워크라고 부르는 이유는 외부 설정정보를 통한 런타임 오브젝트 DI라는 단순한 기능을 제공하기 때문이 아니다. 오히려 스프링이 DI에 담긴 원칙과 이를 응용하는 프로그래밍 모델을 자바 엔터프라이즈 기술의 많은 문제를 해결하는 데 적극적으로 활용하고 있기 때문이다. 또, 스프링과 마찬가지로 스프링을 사용하는 개발자가 만드는 애플리케이션 코드 또한 이런 DI를 활용해서 깔끔하고 유연한 코드와 설계를 만들어낼 수 있도록 지원하고 지지해주기 때문이다.
			=== 메일 서비스 추상화 ===
	* p.384		* p.384
	** 그런데, 과연 테스트를 하면서 매번 메일이 발송되는 것이 바람직한가? 대개는 바람직하지 못하다.		** 그런데, 과연 테스트를 하면서 매번 메일이 발송되는 것이 바람직한가? 대개는 바람직하지 못하다.

imported>linflus at 07:00, 30 July 2011

2011-07-30T07:00:10Z

← Older revision		Revision as of 07:00, 30 July 2011
Line 102:		Line 102:
	** 패턴이나 설계 원칙을 공부하는 이유는 폼나는 용어를 외우고 기계적인 지식을 습득하면 저절로 깔끔하고 유연한 코드가 나오기 때문이 아니다. 좋은 코드를 만들기 위한 개발자 스스로의 노력과 고민이 있을 때 도움을 주기 때문이다.		** 패턴이나 설계 원칙을 공부하는 이유는 폼나는 용어를 외우고 기계적인 지식을 습득하면 저절로 깔끔하고 유연한 코드가 나오기 때문이 아니다. 좋은 코드를 만들기 위한 개발자 스스로의 노력과 고민이 있을 때 도움을 주기 때문이다.
	** 스프링을 DI 프레임워크라고 부르는 이유는 외부 설정정보를 통한 런타임 오브젝트 DI라는 단순한 기능을 제공하기 때문이 아니다. 오히려 스프링이 DI에 담긴 원칙과 이를 응용하는 프로그래밍 모델을 자바 엔터프라이즈 기술의 많은 문제를 해결하는 데 적극적으로 활용하고 있기 때문이다. 또, 스프링과 마찬가지로 스프링을 사용하는 개발자가 만드는 애플리케이션 코드 또한 이런 DI를 활용해서 깔끔하고 유연한 코드와 설계를 만들어낼 수 있도록 지원하고 지지해주기 때문이다.		** 스프링을 DI 프레임워크라고 부르는 이유는 외부 설정정보를 통한 런타임 오브젝트 DI라는 단순한 기능을 제공하기 때문이 아니다. 오히려 스프링이 DI에 담긴 원칙과 이를 응용하는 프로그래밍 모델을 자바 엔터프라이즈 기술의 많은 문제를 해결하는 데 적극적으로 활용하고 있기 때문이다. 또, 스프링과 마찬가지로 스프링을 사용하는 개발자가 만드는 애플리케이션 코드 또한 이런 DI를 활용해서 깔끔하고 유연한 코드와 설계를 만들어낼 수 있도록 지원하고 지지해주기 때문이다.
			* p.384
			** 그런데, 과연 테스트를 하면서 매번 메일이 발송되는 것이 바람직한가? 대개는 바람직하지 못하다.
			** 여기서 지적하지 않았다면 그 부분에 대해 딱히 문제라고 생각하지 않았을 것 같다. - [[김수경]]
			* p.392
			** 서비스 추상화란 이렇게 원활한 테스트만을 위해서도 충분히 가치가 있다. 기술이나 환경이 바뀔 가능성이 있음에도, JavaMail처럼 확장이 불가능하게 설계해놓은 API를 사용해야 하는 경우라면 추상화 계층의 도입을 적극 고려해볼 필요가 있다. 특별히 외부의 리소스와 연동하는 대부분 작업은 추상화의 대상이 될 수 있다.
			* p.396
			** 목 오브젝트는 스텁처럼 테스트 오브젝트가 정상적으로 실행되도록 도와주면서, 테스트 오브젝트와 자신의 사이에서 일어나는 커뮤니케이션 내용을 저장해뒀다가 테스트 결과를 검증하는 데 활용할 수 있게 해준다.
			* p.400
			** 목 오브젝트를 이용한 테스트라는 게, 작성하기는 간단하면서도 기능을 상당히 막강하다는 사실을 알 수 있을 것이다. 보통의 테스트 방법으로는 검증하기가 매우 까다로운 테스트 대상 오브젝트의 내부에서 일어나는 일이나 다른 오브젝트 사이에서 주고받는 정보까지 검증하는 일이 손쉽기 때문이다.
			** 목 오브젝트를 이용한 테스트가 작성하기 간단하…지 않았었는데. - [[김수경]]
	----		----
	[[토비의스프링3]], [[Spring/탐험스터디]]		[[토비의스프링3]], [[Spring/탐험스터디]]