잃어버린 시간을 찾는 개발자

개요 1. 중복 코드 정리 2. 스프링 테스트 적용 3. DI와 테스트 본문 1. 중복 코드 정리 중복 코드 정리는 사실 이전 페이지에서 다루었어야 했는데 건드리지 않고 넘어갔기에 이번 페이지에서 다루겠다. UserDaoTest의 메소드를 살펴보면 중복되는 코드를 발견할 수 있다. 이를 @Before라는 애너테이션을 통해서 먼저 선언 하고 사용하거나, 오브젝트를 픽스처로 선언함으로써 중복을 제거할 수 있다. 아래의 코드를 살펴보면 바로 이해할 수 있을 것이다. public class UserDaoTest { private UserDao dao;//setup() 메소드에서 만드는 오브젝트를 테스트 메소드에서 사용할 수 있도록 인스턴스 변수로 선언 private User user1; //주로 사용하는 오브젝..

개요 1. 테스트 결과의 일관성 2. 포괄적인 테스트 3. 테스트 주도 개발 본문 1. 테스트 결과의 일관성 책에서 소개하고 있는 JUnit의 사용법이나 간단한 소개는 생략하도록 하겠다. 현재까지의 코드는 테스트 결과에 일관성을 가지고 있지 못하다. 테이블에 동일한 ID값을 가지고 있으면 그 값 때문에 입력할 수 없다는 결과가 도출 될 것이다. 이러한 테스트는 좋은 테스트라고 할 수가 없다. 여러번 반복하더라도 동일한 결과를 얻을 수 있는 게 좋은 테스트이기 때문이다. 따라서 실행을 마칠 때마다 테이블을 비워서 실행하기 이전 상태로 돌리는 것이다. 이러한 기능을 실현하기 위해서 UserDao에 테이블을 모두 비우는 deleteAll()메소드와 getCount()메소드를 추가한다. //데이터 모두 삭제 p..

개요 1. UserDaoTest의 특징과 문제점 2. 테스트 검증의 자동화 3. JUnit테스트로 전환 본문 1. UserDaoTest의 특징과 문제점 테스트는 코드를 만들 때 필수적으로 요구되는 일이다. 테스트 없이는 코드가 원하는 대로 작동하는지 확신할 수 없으며 확신 없이 프로그램을 완성한다는 것은 말이 되지 않는 일이다. 1장에서 만들었던 코드도 나름대로 UserDaoTest를 통해서 테스트를 하고 있었다. 이 테스트의 특징을 알아보고 보다 효율적인 테스트 방법에 대해서 배워나가는 것이 이번 장의 목표이다. 테스트는 가능하면 작은 단위로 이루어져야 한다. UserDaoTest는 Dao가 제대로 작동하고 있는 가에 초점이 맞춰져있다. Dao의 기능을 확인하기 위해서 view까지 만들고 서버 환경까지..

개요 1. XML 설정 알고 전환하기 2. DataSource인터페이스로 변환 본문 1. XML 설정 알고 전환하기 xml을 이용하면 설정을 다루기 쉽고 이해하기도 쉽다. 사실 개인 프로젝트로 스프링을 쓸 때는 곧바로 xml을 썼기에 익숙하기도 하다. 개인 프로젝트를 만들 때 명백하게 이해하던 부분이니 간단하게 정리하고 넘어가는 것으로 하겠다. 자바 코드 설정정보 XML 설정정보 빈 설정파일 @Configuration 빈의 이름 @Bean methodName() 기존의 DaoFactory에서 각각의 부분을 xml의 문법으로 전환하여 빈을 정의하면 위와 같이 대응할 수 있다. 실질적인 XML코드로 전환하면 위와 같이 된다.

개요 1. 의존관계 주입이란? 2. 의존관계 검색 3. 의존관계 주입의 응용 본문 1. 의존관계 주입이란? 의존관계란 두 클래스 또는 모듈 사이에서 한쪽 방향으로 영향을 미치는 관계를 의미한다. A가 B에 의존하고 있다고 한다면 B가 변할 경우 A에게 영향이 미치는 관계이다. 반대로 A가 변한다고 해서 B가 변하지는 않는관계이다. 지금까지 작업해온 UserDao를 보면 UserDao가 ConnectionMaker에 의존하고 있는 것을 볼 수 있다. DConnectionMaker라는 클래스의 존재는 알지도 못한다. 이러한 느슨한 관계 속에서 런타임 시에는 DConnection과의 의존관계가 실체화된다. 이러한 관계를 런타임 의존관계 또는 오브젝트 의존관계라고 부르며 DConnection을 의존 오브젝트라고..

개요 1. DaoFactory와 애플리케이션 컨텍스트의 또다른 차이 2. 싱글톤 3. 싱글톤과 오브젝트의 상태 본문 1. DaoFactory와 애플리케이션 컨텍스트의 또다른 차이 DaoFactory와 애플리케이션 컨텍스트의 차이 중 싱글톤으로 구현되었느냐 하는 것이 있다. 설명하기에 앞서 차이를 확인할 수 있는 코드와 결과를 보도록 하겠다. 위 캡쳐본은 기존 DaoFactory로 생성한 dao1, dao2의 객체값 출력과 애플리케이션 컨텍스트로 생성한 dao3, dao4의 객체값을 비교한 것이다. 기존 DaoFactory는 객체값이 생성할 때마다 다르고 애플리케이션 컨텍스트는 같다는 걸 알 수가 있다. 이는 스프링의 경우 객체를 싱글톤으로 만들기 때문에 그렇다. 싱글톤이란 무엇이고 왜 스프링은 싱글톤으로..

개요 1. 스프링 사용 환경 설정 2. 애플리케이션 컨텍스트 작성 3. 스프링 이해 본문 1. 스프링 사용 환경 설정 이제 본격적으로 스프링을 사용해볼 차례다. 이를 위해서는 프로젝트에 라이브러리를 추가해주어야 한다. 라이브러리는 https://mvnrepository.com/ 에서 구할 수 있다. 구글링을 해보면 토비의 스프링 관련 라이브러리를 묶어서 올려놓는 블로그들도 발견할 수 있으니 일일이 검색해서 구하기 귀찮다면 그곳에서 묶음 파일을 받아서 적용해도 된다. 단 이 경우 해당 블로그에서 믿을 수 있는 라이브러리를 올려줬는지 알 수 없기에 불안한 면이 있다. 비단 바이러스를 올렸을 최악의 경우가 아니더라도 버전이 이 달라서 생기는 문제등이 있을 수도 있다. 필자도 어느 블로그에서 다운 받고 그대로 ..

개요 1. 생성의 책임, 기능을 팩토리 클래스로 분리 2. 팩토리 클래스의 기능 확장, 개선 3. 제어의 역전 이해 본문 1. 생성의 책임, 기능을 팩토리 클래스로 분리 이전 코드에서 UserDaoTest에서 D사냐 N사냐를 결정할 수 있게끔 코드를 만들었다. 그러나 UserDaoTest의 만든 본 목적은 UserDao 제대로 작동하느냐 하는 것이다. 따라서 이를 분리할 필요가 있다. 객체의 생성 방법을 결정하고 오브젝트를 돌려주는 팩토리를 만들 필요가 있는 것이다. package springbook.user.ex6.dao; //UserDao의 생성 책임을 맡은 팩토리 클래스 public class DaoFactory { public UserDao userDao() { ConnectionMaker con..

개요 1. 분리의 방법3 - 클래스의 분리 2. 분리의 방법4 - 인터페이스의 도입 3. 관계설정 책임의 분리 본문 1. 분리의 방법3 - 클래스의 분리 앞서 상속을 통해서 서브 클래스로 관심을 분리하는 분리 방법을 적용해보았고 그에 따른 문제점도 언급해 보았다. 슈퍼 클래스와 서브 클래스가 생각보다 긴밀한 관계이기에 현재 책에서 분리한 커넥션과 UserDao를 슈퍼 클래스와 서브 클래스로 분리한 것은 그다지 적합하지 못하다. 따라서 화끈하게 분리할 수 있도록 독립된 클래스로 분리하는 작업을 해보겠다. package springbook.user.ex4.dao; import java.sql.Connection; import java.sql.DriverManager; import java.sql.Prepar..

개요 1. 관심사의 분리의 필요성 2. 분리의 방법1 - 메소드 추출 3. 분리의 방법2 - , 상속을 통한 확장 본문 1. 관심사의 분리의 필요성 모든 것은 융통성있게 확장, 변화할 수 있게 하기 위해서이다. 한 클래스에 필요하다 싶은 대로 떠오르는 대로 코딩하면 작동이야 하겠지만 이후에 수정하거나 다른 기능을 추가하려면 어디가 어떻게 작동하는지 이해하는 것도 어렵고 코드를 수정 추가할 때 분리했을 때보다 더 많은 양의 코드를 수정해야하고, 생각대로 수정했는데 잘못 이해해서 코드가 작동하지 않는 일이 일어날 수도 있다. 이를 피하고 좀 더 효율적인 코딩을 위해서 개발자들은 여러가지 방법론을 만들었고 그 중하나가 분리이다. 변화는 한 가지 관심을 중심으로 일어나고 그 관심을 중심으로 적절히 분리할 수 있..