토비의스프링 썸네일형 리스트형 2.5 학습 테스트로 배우는 스프링 2.5 학습 테스트로 배우는 스프링 학습 테스트 자신이 만들지 않은 프레임워크나 다른 개발팀에서 만들어서 제공한 라이브러리 등에 대해서 작성한 테스트 학습 테스트의 목적 사용할 API나 프레임워크의 기능을 테스트로 보면서 사용 방법을 익히기 위함 자신이 테스트를 만들려고 하는 기술이나 기능에 대해 얼마나 제대로 알고 있는 지를 검증 빠르고 정확하게 사용법을 익히기 위함 테스트 대상보다 테스트 코드 자체에 관심을 가져야 함 2.5.1 학습 테스트의 장점 다양한 조건에 따른 기능을 손쉽게 확인 가능 자동화된 테스트 코드로 만들어지기 때문에 다양한 조건에 따라 기능이 어떻게 동작하는지 빠르게 확인이 가능 학습 테스트 코드를 개발 중 참고 가능 예제를 만드는 방법의 경우 최종 수정 예제만 남게 된다. 학습 테스.. 2.4 스프링 테스트 적용 애플리케이션 컨텍스트 생성 방식 @Before 메소드가 테스드 메소드 개수만큼 반복 반복될 때마다 애플리케이션 컨텍스트가 만들어짐 애플리케이션 컨텍스트 생성 시 모든 싱글톤 빈 오브젝트를 초기화하므로 제법 많은 시간을 필요로 함 테스트는 가능한 독립적으로 매번 새로운 오브젝트를 사용하는 것이 원칙 애플리케이션 컨텍스트처럼 시간과 자원이 많이 소모되는 경우 테스트 전체가 공유하는 오브젝트를 만들기도 함 다만, 이 때도 테스트는 일관성이 있어야하며, 테스트 순서에 영향을 받지 말아야한다. 애플리케이션 컨텍스트의 경우 초기화되고 나면 내부 상태가 변경되는 일이 거의 없으므로 무관함 문제는 JUnit이 매번 테스트 클래스의 오브젝트를 새로 생성함. 여러 테스트가 함께 참조할 애플리케이션 컨텍스트를 오브젝트 레벨.. 2.3 개발자를 위한 테스팅 프레임워크 JUnit 목차 2.3.1 JUnitTest 실행 방법 IDE 빌드툴 2.3.2 테스트 결과의 일관성 deleteAll()의 getCount() 추가 deleteAll()과 getCount()의 테스트 동일한 결과를 보장하는 테스트 2.3.3 포괄적인 테스트 getCount() 테스트 addAndGet() 테스트 보완 get() 예외조건에 대한 테스트 테스트를 성공시키기 위한 코드의 수정 포괄적인 테스트 2.3.4 테스트가 이끄는 개발 기능설계를 위한 테스트 테스트 주도 개발 2.3.5 테스트 코드 개선 @Before 픽스처 2.3.1 JUnit 테스트 실행 방법 JUnitCore를 이용해 테스트를 실행할 수도 있지만, 테스트의 수가 많아지고 복잡해지면 관리하기가 힘들어짐 IDE 이클립스, STS는 JUnit 테스.. 2.2 UserDaoTest 개선 목차 2.2.1 테스트 검증의 자동화 2.2.2 테스트의 효율적인 수행과 결과 관리 JUnit 테스트로 전환 테스트 메소드 전환 검증 코드 전환 JUnit 테스트 실행 2.2.1 테스트 검증의 자동화 add()에 전달한 User 오브젝트와 get()을 통해 가져와 User 오브젝트의 정보가 서로 일치하는가 테스트 에러 : 테스트 진행 중 에러(Exception 등)가 발생 테스트 실패 : 에러는 발생하지 않았지만, 결과값이 다를 때 '조회 성공'은 에러가 발생하지 않았음을 의미할 뿐 테스트의 실패 여부는 알 수 없음 수정한 UserDaoTest() public static void main(String[] args) throws ClassNotFoundException, SQLException{ // ... 1장. 오브젝트와 의존관계 개요 스프링은 자바를 기반으로 한 기술이다. 가장 중요하게 생각하는 가치 : 객체지향 가장 관심을 많이 두는 대상 : 오브젝트 목차 1.1 초난감 DAO 1.1.1 User 1.1.2 UserDao 1.1.3 main()을 이용한 DAO 테스트 코드 1.2 DAO의 분리 1.2.1 관심사의 분리 1.2.2 커넥션 만들기의 추출 UserDao의 관심사항 중복 코드의 메소드 추출 변경 사항에 대한 검증: 리팩토링과 테스트 1.2.3 DB 커넥션 만들기의 독립 상속을 통한 확장 1.3 DAO의 확장 1.3.1 클래스의 분리 1.3.2 인터페이스의 도입 1.3.3 관계설정 책임의 분리 1.3.4 원칙과 패턴 개방 폐쇄 원칙 높은 응집도와 낮은 결합도 전략 패턴 1.4 제어의 역전(IoC) 1.4.1 오브젝트 팩.. 1.9 정리 책임이 다른 코드를 분리하여 두 개의 클래스를 만듦(관심사의 분리, 리팩토링) 바뀔 수 있는 쪽의 클래스는 인터페이스를 구현하고, 다른 클래스는 인터페이스를 통해 접근(전략 패턴) 자신의 책임 자체가 변경되는 경우 외에는 불필요한 변화가 발생하지 않도록 막아주고, 자신이 사용하는 외부 오브젝트의 기능은 자유롭게 확장하거나 변경할 수 있도록 만듦(개방 폐쇄 원칙) 한쪽의 기능 변화가 다른 쪽은 기능 변경을 요구하지 않아도 되며(낮은 결합도), 자신의 책임과 관심사에만 순수하게 집중(높은 응집도)할 수 있게 됨 오브젝트가 생성되고 여타 오브젝트와 관계를 맺는 작업의 제어권을 별도의 오브젝트 팩토리 또는 IoC 컨테이너로 넘겨서 오브젝트가 자신이 사용할 대상의 생성이나 선택에 관한 책임으로부터 자유롭게 만들어.. 1.8 XML을 이용한 설정 1.8.1 XML 설정 DI정보가 담긴 XML : 를 루트 엘리먼트로 사용 여러 개의 을 정의할 수 있음 @Configuration과 @Bean이 붙은 자바 클래스와 설정이 동일 @Congiguration - // @Bean - 에 대응 하나의 @Bean 메소드에서 얻을 수 있는 빈의 DI 정보 빈의 이름 : @Bean 메소드 이름, getBean()에서 사용 빈의 클래스 : 빈 오브젝트를 어떤 클래스를 이용해서 만들지를 정의 빈의 의존 오브젝트 : 빈의 생성자나 수정자 메소드를 통해 의존 오브젝트를 주입 connectionMaker() 전환 클래스 설정과 XML 설정의 대응항목 자바 코드 설정정보 XML 설정정보 빈 설정파일 @Configuration 빈의 이름 @Bean methodName() 빈의 .. 1.7 의존관계 주입(DI) 1.7.1 제어의 역전(IoC)와 의존관계 주입 IoC는 매우 폭 넓게 사용되는 용어이므로, 스프링이 제공하는 IoC 방식은 의존관계 주입(Dependency Injection)이라는 용어를 사용한다. 1.7.2 런타임 의존관계 설정 의존관계 A가 B에 의존한다. B가 변하면 A에 영향을 미친다. UML에서 점선 화살표로 표시함 (A ---> B) 방향성을 가지고 있으므로 반대는 성립하지 않는다. 즉, A가 변해도 B는 영향을 받지 않는다. UserDao의 의존관계 UserDao ---> ConnectionMaker ConnectionMaker 인터페이스가 변하면 UserDao는 변해야한다. 그러나, ConnectionMaker를 구현한 DConnectionMaker에는 의존하지 않으므로 DConnect.. 이전 1 2 3 4 5 다음
