이전 장(3.2)에서는 전략 패턴을 사용해서 변하는 부분과 그렇지 않은 부분을 깔끔하게 분리했다. public void deleteAll() throws SQLException { StatementStrategy strategy = new DeleteAllStatement(); // 선정한 전략 클래스의 오브젝트 생성 jdbcContextWithStatementStrategy(strategy); // 컨텍스트 호출, 전략 오브젝트 전달 } 클라이언트 코드에서 구체적인 전략을 정하고, 컨텍스트에 그 전략을 파라미터로 전달해주었다. 컨텍스트도 jdbcContextWithStatementStrategy라는 메소드로 분리하였더니 다른 DAO에서도 PreparedStatement를 실행하는 JDBC의 공통 작업 ..

1장에서 초난감 DAO 코드에 DI를 적용하면서 관심사가 다른 코드를 분리하였으며, 변경과 확장에 유연한 구조로 변경하였다. 이는 개방 폐쇄 원칙(OCP)을 잘 준수했다고 볼 수 있다. 3장에서는 템플릿에 대해 학습한다. 템플릿이란 변경이 거의 일어나지 않는 부분을 자유롭게 변경되는 부분과 독립시켜서 효과적으로 활용할 수 있도록 하는 방법이다. 3장에서 스프링에 적용된 템플릿 기법을 살펴보자. 3.1 다시 보는 초난감 DAO 아직 UserDao의 코드에는 문제점이 남아 있다. 예외 상황에 대한 처리가 부족하다. 한번 살펴보자. 3.1.1 예외처리 기능을 갖춘 DAO JDBC 코드에는 예외 처리를 반드시 해주어야 한다. 정상적인 JDBC 코드의 흐름을 따르지 않고 중간에 예외가 발생한 경우 사용한 리소스를..

기존의 테스트코드에서 @Before 메소드가 테스트 메소드 개수만큼 반복된다. @Before public void setUp(){ Application Context ac = new GenericXmlApplicationContext("applicationContext.xml"); this.dao = ac.getBean("userDao", UserDao.class); } 현재 @Before 메소드는 애플리케이션 컨텍스트를 생성하는 코드를 수행하는데, 애플리케이션 컨텍스트는 생성될 때 모든 싱글톤 빈 오브젝트를 초기화한다. 어떤 빈은 오브젝트가 생성될 때 자체적인 초기화 작업을 진행하는 경우도 있다. 이 경우 빈 오브젝트 초기화에 많은 시간이 할애된다. 또, 애플리케이션 컨텍스트가 초기화될 때 어떤 빈은 ..

2.2.1 테스트 검증의 자동화 테스트의 결과는 성공과 실패로 나뉜다. 실패는 테스트를 진행하는 동안에 에러가 발생하는 경우와, 에러가 발생하지 않았지만 결과가 기대한 바와 다른 경우로 나뉜다. 전자를 테스트 에러, 후자를 테스트 실패라고 구분한다. 테스트 중 에러가 발생하는 것은 콘솔에 출력되므로 쉽게 확인이 가능하다. 하지만 실패하는 것은 별도의 확인 작업과 그 결과가 있어야 알 수 있다. 테스트 코드를 다음과 같이 변경해보자. if(!user.getName().equals(user2.getName()){ System.out.println("테스트 실패 (name)"); }else if(!user.getPassword().equals(user2.getPassword()){ System.out.prin..

JUnit 프레임워크를 자세히 살펴본다. 스프링의 핵심 기능 중 하나인 스프링 테스트 모듈도 JUnit을 이용한다. 따라서 JUnit은 스프링을 활용하려면 꼭 사용할 줄 알아야 한다. 2.3.1 JUnit 테스트 실행 방법 IDE와 빌드툴로 테스트 실행이 가능한데, IDE가 손쉽고 빠른 테스트를 제공한다. 실행 방법은 따로 포스팅 할 것이 없어 해당 절은 생략한다. 2.3.2 테스트 결과의 일관성 JUnit을 적용해서 테스트 코드를 만들었으나, 아직 개선할 점이 남아있다. 가장 불편했던 점은, 매번 테스트를 실행하기 전에 DB의 USER 테이블 데이터를 지워야 했다는 것이다. 깜빡 잊고 그냥 실행한 경우, 등록된 사용자 정보와 기본키가 중복된다면서 add() 메소드 실행중에 에러가 발생할 것이다. 이 경..