'Framework/Spring' 카테고리의 글 목록

Framework/Spring

(2) 테스트 2020.06.21 2
(1) 오브젝트와 의존관계 2020.06.15

(2) 테스트

2020. 6. 21. 09:03

1. 서론

이번 포스팅에서는 2장인 테스트에 대해 알아보도록 하겠습니다.

2. UserDaoTest 다시보기

스프링이 개발자에게 제공하는 가장 중요한 것은 객체지향적인 설계와 테스트입니다.

테스트는 만들어진 코드를 확신할 수 있게 해주며, 변화에 유연하게 대처할 수 있는 자신감을 가져다 줍니다.

일반적인 웹 프로그램에서 테스트를 할 때, 개발자들은 실수를 합니다.

바로, 서비스 계층, MVC 프레젠테이션 계층, JSP 계층까지 모두 개발을 완료한 후 브라우저 혹은 curl과 같이 직접 http request를 통해

어찌보면 한 요청의 통합테스트를 진행한다는 점입니다.

물론, 바로 원하는 대로 동작을 하면 좋겠지만 기본적으로 개발자들은 자신이 만든 코드를 의심해야합니다.

실패 시, 어느 계층에서 에러가 발생했는지 트레이싱이 힘들며 변화에 있어서 유연하지 못합니다.

작은 단위의 테스트

위 같은 문제를 해결하기 위해 개발자들은 가능한 작은 단위로 테스트를 작성하고 수행해야 합니다.

이런 작은 단위의 코드를 테스트하는 것을 단위테스트( = Unit Test )라고 일컫습니다.

이 단위 테스트의 장점은 개발자가 설계하고 만든 코드가 원래 의도한 대로 동작하는지를 개발자 스스로 빠르게 확인받을 수 있다는 점입니다.

그렇다면, 단위 테스트만 있으면 되고 위에 같이 한 요청에 대한 통합 테스트는 필요 없을까요?

아닙니다. 각 단위의 기능은 테스트시 통과 할 지라도 기능들을 엮었을 땐, 실패할 때가 있기 때문에 단위 테스트 다음엔 통합 테스트로 각 단위의 조합까지 테스트를 하는 것이 가장 이상적입니다.

그럼, 1장에서 만들었던 UserDaoTest를 봐보겠습니다.

UserDaoTest는 아래와 같습니다.

public class UserDaoTest {

    public static void main(String[] args) throws SQLException, ClassNotFoundException {

        ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");

        UserDao dao = context.getBean("userDao", UserDao.class);
        
        User user = new User();
        user.setId("user");
        user.setName("백기선");
        user.setPassword("married");
        
        dao.add(user);

        System.out.println(user.getId() + " 등록 성공");
        
        User user2 = dao.get(user.getId());
        System.out.println(user2.getName());
        System.out.println(user2.getPassword());

        System.out.println(user2.getId() + " 조회 성공");
    }
}

여기에는 몇가지 문제점이 있습니다.

수동 확인 작업의 번거로움 : 기능에 대한 검증을 사람이 직접 콘솔에 찍히는 것을 보고 수동 확인해야 한드는 점입니다.
실행 작업의 번거로움 : 하나의 Dao에 main문을 만들었기 때문에, 매번 테스트를 수행하기 위해서는 main을 수행해야 하며, Dao가 많아 질수록 main 문이 늘어난다는 점입니다.

3. UserDaoTest 개선

위 UserDaoTest의 문제점들을 단계적으로 개선하겠습니다.

먼저, 수동 확인의 번거로움입니다.

현재는 콘솔에 찍히는 "등록 성공" 과 "조회 성공"으로 테스트 통과여부를 판단하고 있습니다.

그렇다면 저 2개의 콘솔 출력만 된다면 성공일까요?

아닙니다. 테스트는 에러가 나지 않았더라도 예상한것과 다르게 기능이 동작했을 수 있기 때문입니다.

때문에 아래와 같이 코드를 수정하겠습니다.

if (!user.getName().equals(user2.getName())) {
    System.out.println("테스트 실패 (name)");    
} else if (!user.getPassword().equals(user2.getPassword())) {
    System.out.println("테스트 실패 (password)");
} else {
    System.out.println("조회 테스트 성공");
}

이제, name과 password를 일일이 수동 확인하지 않고 콘솔 출력으로 "조회 성공" 만 나오는것으로 테스트 확인이 가능해졌습니다.

만약, 값이 이상하게 저장되었다면 콘솔 출력된것을 보고 수정 후 다시 한번 테스트를 수행하면 될 것입니다.

하지만, 여기에도 문제점은 존재합니다.

우선 if - else if - else 문으로 인해 User에 대해 검증할 필드들이 늘어날 수록 코드의 장황함은 커질 것 입니다.

또한, 콘솔 출력을 일일이 확인해야 하기 때문에 완벽히 수동 확인의 번거로움을 해소한것이 아닙니다.

이런 부분은 실행 부분의 번거로움을 개선하기 위해 사용할 JUnit 테스트로 전환하면서 같이 개선이 되어집니다.

JUnit 이란, 자바로 단위 테스트를 만들때 사용할 수 있는 프레임워크로 스프링과 궁합이 좋습니다.

JUnit 은 위와 같이 main 문이 필요없으며, 제공하는 어노테이션들을 사용하여 손쉽게 테스트 코드 작성과 검증이 가능합니다.

아래는 UserDaoTest에 JUnit을 적용한 코드입니다.

public class UserDaoTest {
    
    @Test
    public void addAndGet() throws SQLException, ClassNotFoundException {
        ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");

        UserDao dao = context.getBean("userDao", UserDao.class);

        User user = new User();
        user.setId("gyumee");
        user.setName("박성철");
        user.setPassword("springno1");

        dao.add(user);

        System.out.println(user.getId() + " 등록 성공");

        User user2 = dao.get(user.getId());

        Assertions.assertEquals(user2.getName(), user.getName());
        Assertions.assertEquals(user2.getPassword(), user.getPassword());
    }
}

@Test 어노테이션과, public void 형식으로 선언되어 있다면 JUnit에서는 테스트를 원하는 소스로 판단하여 테스트를 수행하게 됩니다.

여기서, 또 한가지 볼 수 있는것은 Assertions.assertEquals 메서드입니다.

이는 junit에서 제공하는 메서드로서 기대값과 실제값을 인자로 받아 개발자가 예상한 값과 같은지 확인합니다.

위, Assertions.assertEquals 메서드는 junit 버전에 따라 약간 상이할 수 있습니다.

JUnit에서는 위와 같은 방법으로 굳이 불필요한 콘솔 출력이 필요 없게 되며 main 문도 사라졌습니다.

또한, 한 테스트 클래스에 여러개의 @Test 어노테이션을 통해 테스트 코드의 확장도 가능해졌습니다.

4. 개발자를 위한 테스팅 프레임워크 JUnit

자바 개발자는 필수적으로 Junit을 사용할 수 있어야합니다.

이러한, Junit 은 일반적으로 이클립스 혹은 인텔리제이과 같은 IDE에서 모두 지원이 되므로 편하게 사용할 수 있습니다.

ide가 아닌 메이븐, 그래들과 같은 빌드 툴로도 테스트 수행은 가능합니다.

위 UserDaoTest에는 사실 아직도 문제점이 있습니다. 바로 테스트 결과의 일관성이 침해한다는 점입니다.

addAndGet를 테스트한 후에는 DB에 데이터를 지워야 다음에 테스트틀 다시 수행할 때 영향이 없기 때문입니다.

그렇다는것은 해당 테스트는 DB 데이터에 의존성이 강하게 있다는 것을 의미합니다.

단위 테스트는 코드가 바뀌지 않는다면, 매번 실행할 때마다 동일한 테스트 결과를 얻을 수 있어야 합니다.

이를, 개선하기 위해 아래 2개의 메서드를 추가하도록 하겠습니다.

deleteAll()
getCount()

public void deleteAll() throws SQLException, ClassNotFoundException {
    Connection c = connectionMaker.makeConnection();
    
    PreparedStatement ps = c.prepareStatement("delete from users");
    ps.executeUpdate();
    
    ps.close();
    c.close();
}

public int getCount() throws SQLException, ClassNotFoundException {
    Connection c = connectionMaker.makeConnection();
    PreparedStatement ps = c.prepareStatement("select count(*) from users");
    
    ResultSet rs = ps.executeQuery();
    rs.next();
    int count = rs.getInt(1);
    
    rs.close();
    ps.close();
    c.close();
    
    return count;
}

위와 같은, 기능을 추가하였으니 이를 확인하기 위해 테스트 코드 또한 작성해보겠습니다.

public class UserDaoTest {

    @Test
    public void addAndGet() throws SQLException, ClassNotFoundException {
        ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");

        UserDao dao = context.getBean("userDao", UserDao.class);
        
        dao.deleteAll();
        Assertions.assertEquals(dao.getCount(), 0);
        
        User user = new User();
        user.setId("gyumee");
        user.setName("박성철");
        user.setPassword("springno1");

        dao.add(user);
        Assertions.assertEquals(dao.getCount(), 1);

        User user2 = dao.get(user.getId());

        Assertions.assertEquals(user2.getName(), user.getName());
        Assertions.assertEquals(user2.getPassword(), user.getPassword());
    }
}

이제, addAndGet 을 수행 할 시 deleteAll 로 인해 테스트 수행 후 DB에 데이터를 직접 지우는 불필요한 작업은 없어졌습니다.

또한, getCount을 통하여 deleteAll과 add 메서드에 대해 검증작업 또한, 추가되었습니다.

하지만 위에는 getCount가 정상적으로 동작했을때를 가정되어 있기 때문에, getCount에 대한 테스트도 필요합니다.

@Test
public void count() throws SQLException, ClassNotFoundException {
    ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");
    UserDao dao = context.getBean("userDao", UserDao.class);
    
    User user1 = new User("gyumee", "springno1", "박성철");
    User user2 = new User("leegw700", "springno2", "이길원");
    User user3 = new User("bumjin", "springno3", "박범진");
    
    dao.deleteAll();
    Assertions.assertEquals(dao.getCount(), 0);

    dao.add(user1);
    Assertions.assertEquals(dao.getCount(), 1);

    dao.add(user2);
    Assertions.assertEquals(dao.getCount(), 2);
    
    dao.add(user3);
    Assertions.assertEquals(dao.getCount(), 3);
}

count 테스트를 위해 user를 하나씩 넣어가며 확인을 하였습니다.

이제 어느정도 UserDao에 대해 테스트가 된 것 같습니다.

하지만, 아직 조금 꺼림칙한 부분이 있습니다. 바로 get 메서드입니다.

get으로 받은 id 값이 DB에 없을때가 있기 때문입니다.

이런경우, 흔히 null을 반환하도록 혹은 예외를 일으키는 방법중에 선택을 합니다.

여기서는, 후자인 예외를 일으키는 방법을 사용하겠습니다.

아래와 같이 테스트 코드를 추가하겠습니다.

@Test
public void getUserFailure() throws SQLException, ClassNotFoundException {
    ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");
    UserDao dao = context.getBean("userDao", UserDao.class);

    dao.deleteAll();
    Assertions.assertEquals(dao.getCount(), 0);

    Assertions.assertThrows(EmptyResultDataAccessException.class, dao.get("unknown_id"));
}

위는 예외를 일으켜야 성공하는 테스트 코드입니다.

예외는 지정한 EmptyResultDataAccessException 예외가 일어나야 합니다.

이제 위 테스트 코드를 성공시키기 위해 dao의 get 메서드를 수정하겠습니다.

public User get(String id) throws ClassNotFoundException, SQLException {
    Connection c = connectionMaker.makeConnection();
    PreparedStatement ps = c.prepareStatement("select * from users where id = ?");
    ps.setString(1, id);

    ResultSet rs = ps.executeQuery();
    User user = null;
    if (rs.next()) {
        user =  new User();
        user.setId(rs.getString("id"));
        user.setName(rs.getString("name"));
        user.setPassword(rs.getString("password"));
    }
    
    rs.close();
    ps.close();
    c.close();
    
    if (user == null) throw new EmptyResultDataAccessException(1);
    return user;
}

이제 get 메서드시 데이터가 없다면 예외를 일으키며, 테스트 또한 성공하게 될 것입니다.

이렇게, 개발자들은 항상 실패 케이스에 대해서 생각을 하며 테스트를 해야합니다.

책에서는, 이런 부정적인 케이스를 먼저 만드는 습관을 들이는걸 추천합니다.

추가로, 독자들은 지금 테스트 주도 개발인 TDD을 체험하였습니다.

TDD란 테스트를 먼저 만들고 그 테스트가 성공하도록 코드를 만드는 방식입니다.

위 getUserFailure 테스트를 먼저 만들고 이를 성공시키기 위해 get 메서드를 수정한것과 같이 말입니다.

TDD의 장점은 코드를 만들어 테스트를 실행하는 그 사이의 간격이 매우 짦다는 점입니다.

이제 UserDaoTest 를 마지막으로 리팩토링 해보겠습니다. 리팩토링의 대상은 어플리케이션 뿐만이 아닌 테스트 코드도 포함입니다.

UserDaoTest 를 보니 UserDao 빈을 가져오는 부분이 계속 중복됩니다.

어플리케이션 코드였다면 이를 별도의 메서드로 추출이 가능했습니다.

하지만, JUnit에서는 각 @Test 수행 전 세팅을 하는 기능을 제공합니다.

바로 @Before 어노테이션이 붙은 메서드를 활용한것으로 코드는 아래와 같이 변경됩니다.

public class UserDaoTest {
    private UserDao userDao;

    @BeforeEach
    public void setUp() {
        ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");
        this.userDao = context.getBean("userDao", UserDao.class);
    }

    ...
}

junit은 각 테스트 메서드별로 테스트 클래스를 인스턴스화하여 사용합니다.

때문에, 위와 같이 userDao를 인스턴스 변수로 선언하여 사용해야 합니다.

아래는, JUnit의 테스트 메서드 실행 방법이 어떻게 동작하는지에 대한 그림입니다.

JUnit 에서는 테스트를 수행하는데 필요한 정보나 오브젝트를 픽스처라고 합니다.

위 UserDao 오브젝트도 픽스처에 해당하며 테스트에서 쓰였던 User 오브젝트들도 픽스처로 뽑을 수 있습니다.

public class UserDaoTest {
    
    private UserDao userDao;
    private User user1, user2, user3;
    
    @BeforeEach
    public void setUp() {
        ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");
        this.userDao = context.getBean("userDao", UserDao.class);
        this.user1 = new User("gyumee", "springno1", "박성철");
        this.user2 = new User("leegw700", "springno2", "이길원");
        this.user3 = new User("bumjin", "springno3", "박범진");
    }
    ...

}

5. 스프링 테스트 적용

이제 UserDaoTest 클래스에서 더는 개선할 포인트가 없을까요?

JUnit은 매 테스트마다 테스트 클래스가 인스턴스되어 수행된다고 했습니다.

그렇다면, ApplicationContext도 역시 @Test 갯수만큼 생성이 됩니다.

하지만, Application 같은 경우에는 bean의 관리 및 DI를 해주는 역할로 굳이 각 인스턴스 변수로 있을 필요가 없습니다.

또한, Application은 초기화 비용이 크기 때문에 테스트 수행시간은 느려지게 될 것입니다.

테스트 코드는 가능한 빠르고 독립적이어야 좋은 테스트 코드입니다.

스프링에서는 이를 위해 JUnit을 이용한 편의성을 추가로 제공합니다.

이런 부분에서 스프링과 JUnit은 궁합이 잘 맞는다고 할 수 있습니다.

아래는 스프링 테스트 컨텍스트 프레임워크를 적용한 UserDaoTest 코드입니다.

junit 5 이하 버전에서는 @ExtendWith(SpringExtension.class)가 아닌 @RunWith(SpringRunner.class)로 사용하면 됩니다.

@ExtendWith(SpringExtension.class)
@ContextConfiguration(locations = "/applicationContext.xml")
public class UserDaoTest {
    
    @Autowired
    private ApplicationContext context;
    
    private UserDao userDao;
    private User user1, user2, user3;
    
    @BeforeEach
    public void setUp() {
        this.userDao = context.getBean("userDao", UserDao.class);
        this.user1 = new User("gyumee", "springno1", "박성철");
        this.user2 = new User("leegw700", "springno2", "이길원");
        this.user3 = new User("bumjin", "springno3", "박범진");
    }
    
    ...
}

SpringExtension 은 spring-test 에서 제공하는 클래스로서 테스트를 진행하는 중에 테스트가 사용할 어플리케이션 컨텍스트를 만들고 관리하는 작업을 진행해줍니다.

때문에, 위와 같이 변경하게되면 각 테스트가 돌아갈 때 인스턴스는 다르더라도 context의 인스턴스는 공유하게 됩니다.

따라서, 수백개의 테스트 코드가 있더라도 이제 context의 초기 비용은 처음 테스트 코드에서만 들고 다음부턴 들지 않아 빠른 속도로 수행됩니다.

만약, context를 공유하지 않고 싶다면 class 위에 @DirtiesContext 를 붙여줍니다.
@DirtiesContext를 사용할 시에는 context를 공유하지 않고 새로 만들어서 사용하게 됩니다.

여기서 1장 정확히 이해한 사람은 위에 @Autowired로 인해 ApplicationContext 가 DI 된다는것에 의문을 가져야 합니다.

이유는, ApplicationContext 라는 것을 스프링에게 bean으로 만들어서 관리해달라는 코드가 어디에도 없기 때문입니다.

기본적으로 스프링 컨텍스트는 자기 자신도 bean화 하여 컨테이너에 등록하며, 그로인해 위와 같은 소스가 성공적으로 수행될 수 있습니다.

추가로, @Autowired DI가 걸리는 방법은 아래와 같습니다.

선언 클래스 타입이 빈컨테이너에 있는지 확인, 1개가 있다면 해당 빈 반환
같은 타입이 2개 이상인 경우 변수명과 동일한 빈 id가 있는지 확인 후 있다면 반환

만약, 위 2개 타입과 변수명으로도 빈을 찾지못한다면 스프링은 예외를 발생시킵니다.

테스트와 DI

아래와 같은 특징들로 인해 테스트 코드에서도 운영코드와 같이 DI를 적용해야 합니다.

소프트웨어 개발에서 절대로 바뀌지 않는 것은 없기 때문입니다.
클래스의 구현 방식은 바뀌지 않는다고 하더라도 인터페이스를 두고 DI를 적용하게 해두면 다른 차원의 서비스 기능을 도입할 수 있기 때문입니다.
효율적인 테스트를 손쉽게 만들기 위해서 입니다.

이제, UserDaoTest 에서 마지막으로 할 일이 있습니다. 바로, 테스트용 DI xml 파일을 만드는 것입니다.

DB의 경우에는 운영과 개발, 로컬 모두 주소와 username, password가 다를 수 있습니다.

때문에, 테스트를 위한 별도 설정 정보를 만들어 사용하는것이 안전하며 관리가 용이합니다.

아래와 같이 applicationContext-text.xml 을 만들어 테스트코드에서 이 xml 파일을 보도록 변경시킵니다.

@ExtendWith(SpringExtension.class)
@ContextConfiguration(locations = "/applicationContext-test.xml")
public class UserDaoTest {

    @Autowired
    private ApplicationContext context;
    
    private UserDao userDao;
    private User user1, user2, user3;
    
    ...
}

DI을 이용한 테스트 방법 선택

스프링 기반 프로젝트에서는 테스트코드를 모두 테스트 컨테이너를 구동하는 방식으로 사용해야 할까요?

정답은 아닙니다.

위에서 살펴본것처럼 @ExtendWith가 없어도 테스트는 모두 동일하게 수행되어 집니다.

오히려, 어떤 경우에는 스프링 컨테이너 없이 만드는 것이 스프링과의 의존성 없이 클래스 메서드에 대해서 순수하게 테스트하는 것입니다.

개발자는 우선적으로는 스프링 컨테이너 없이 테스트코드를 작성하려고 해야하며, 테스트 하려는 클래스가 여러 클래스와 의존관계가 있는 경우에는 스프링 컨테이너를 도입하여 테스트 코드를 작성해야 합니다.

물론, 의존관계 자체를 테스트할 때도 컨테이너는 필요합니다.
하지만 DI를 생성자 주입 방식으로 한다면 컨테이너가 없어도 클래스의 주입방식을 충분히 테스트가 가능합니다.
때문에, 스프링에서는 생성자 주입 방식을 권장합니다.

6. 학습 테스트로 배우는 스프링

학습 테스트란, 자신이 아닌 제 3자의 코드에 대해서 대신 테스트 코드를 작성하는 것을 말합니다.

이런 학습테스트로 얻을 수있는 장점은 아래와 같습니다.

다양한 조건에 따른 기능을 손쉽게 확인해볼 수 있습니다.
학습 테스트 코드를 개발 중에 참고할 수 있습니다.
프레임워크나 제품을 업그레이드 할 때 호환성 검증을 도와줍니다.
테스트 작성에 대한 좋은 훈련이 됩니다.
새로운 기술을 공부하는 과정이 즐거워집니다

1) 버그 테스트

버그테스트란, 코드에 오류가 있을 때 그 오류를 가장 잘 드러내 줄 수 있는 테스트입니다.

버그테스트는 일단, 실패하도록 만들어야 합니다. 후에 이 테스트가 성공하도록 운영코드를 수정하는 것입니다.

위에 TDD를 말했을때와 똑같다고 생각하시면 됩니다.

이러한, 버그테스트는 아래와 같은 장점이 있습니다.

테스트의 완성도를 높여줍니다.
버그의 내용을 명확하게 분석하게 해줍니다.
기술적인 문제를 해결하는데 도움이 됩니다.

7. 마무리

이번 포스팅에서는 2장 테스트에 대해 알아봤습니다.

다음에는 3장 템플릿에 대해 포스팅하겠습니다.

'Framework > Spring' 카테고리의 다른 글

(1) 오브젝트와 의존관계 (0)	2020.06.15

(1) 오브젝트와 의존관계

2020. 6. 15. 00:35

1. 서론

이번 포스팅에서는 토비의 스프링 3.1의 1장인 오브젝트와 의존관계 에 대해 알아보도록 하겠습니다.

2. 초난감 DAO

스프링은 자바 언어 기반의 프레임워크입니다.

때문에, 객체지향 프로그래밍이 제공하는 폭넓은 혜택을 누릴 수 있도록 기본으로 돌아가자는 것이 스프링의 핵심입니다.

스프링은 객체지향 설계와 구현을 특정하도록 강요하지는 않습니다.

다만, 효과적으로 설계와 구현을 할 수 있도록 기준을 마련하여 개발자에게 편리함을 제공합니다.

아래는 책에 나오는 DB에 데이터를 추가 및 조회할 수 있는 예제입니다.

@Setter
@Getter
public class User {
    private String id;
    private String name;
    private String password;
}

public class UserDao {

    public void add(User user) throws ClassNotFoundException, SQLException {
        Class.forName("com.mysql.jdbc.Driver");
        Connection c = DriverManager.getConnection("jdbc:mysql://localhost/springbook", "spring", "book");
        PreparedStatement ps = c.prepareStatement("insert into users(id, name, password) values(?, ?, ?)");
        ps.setString(1, user.getId());
        ps.setString(2, user.getName());
        ps.setString(3, user.getPassword());

        ps.executeUpdate();

        ps.close();
        c.close();
    }

    public User get(String id) throws ClassNotFoundException, SQLException {
        Class.forName("com.mysql.jdbc.Driver");
        Connection c = DriverManager.getConnection("jdbc:mysql://localhost/springbook", "spring", "book");
        PreparedStatement ps = c.prepareStatement("select * from users where id = ?");
        ps.setString(1, id);

        ResultSet rs = ps.executeQuery();
        rs.next();
        User user = new User();
        user.setId(rs.getString("id"));
        user.setName(rs.getString("name"));
        user.setPassword(rs.getString("password"));

        rs.close();
        ps.close();
        c.close();

        return user;
    }

}

위 예제코드는 정상적으로 동작하나 사실은 문제가 많은 코드입니다.

개발자가 실제로 이러한 코드를 본다면... 경악을 금치 못할것입니다.

이제 아래 DAO의 분리와 DAO의 확장을 통해 위의 코드를 리팩토링하며 좀 더 나은 객체지향 설계로 변경하도록 하겠습니다.

3. DAO의 분리

위 예제를 리팩토링하기 전에, 먼저 관심사 분리에 대해서 설명하겠습니다.

자바 프로그램은 객체지향 장점으로 지속적인 변화에 매우 유용한 언어입니다.

그렇다면, 객체지향 장점이 그럼 무엇일까요?

바로, 관심사의 분리입니다.

즉, 관심이 같은 것끼리는 하나로 관심이 다른 것은 다르게 하여 실제 세계의 개념들을 객체라는 것으로 만들 수 있는 것을 의미합니다.

그렇다면, 위 초난감 DAO의 관심사항은 무엇일까요?

아마, 아래와 같은 관심사항으로 정의할 수 있습니다.

DB와 연결을 위한 커넥션을 어떻게 가져올까라는 관심.
사용자 등록을 위해 DB에 보낼 SQL 문장을 담을 Statement를 만들고 실행하는 관심
작업이 끝나면 리소스인 Statement와 Connection 오브젝트를 닫아, 리소스 낭비를 일으키지 않는 관심

먼저, 중복 코드인 DB 연결 코드를 메소드로 추출하는 작업을 해보겠습니다.

현재는 2개의 메소드 밖에 없지만, 메소드가 10개 100개가 된다면 메소드를 만들 때 마다 Connection 소스가 중복으로 존재하게 됩니다.

아래는 getConnection이라는 메소드를 통해 DB 연결을 하는 중복코드를 제거한 코드입니다.

public class UserDao {

    public void add(User user) throws ClassNotFoundException, SQLException {
        Connection c = getConnection();
        PreparedStatement ps = c.prepareStatement("insert into users(id, name, password) values(?, ?, ?)");
        ps.setString(1, user.getId());
        ps.setString(2, user.getName());
        ps.setString(3, user.getPassword());

        ps.executeUpdate();

        ps.close();
        c.close();
    }

    public User get(String id) throws ClassNotFoundException, SQLException {
        Connection c = getConnection();
        PreparedStatement ps = c.prepareStatement("select * from users where id = ?");
        ps.setString(1, id);

        ResultSet rs = ps.executeQuery();
        rs.next();
        User user = new User();
        user.setId(rs.getString("id"));
        user.setName(rs.getString("name"));
        user.setPassword(rs.getString("password"));

        rs.close();
        ps.close();
        c.close();

        return user;
    }
    
    private Connection getConnection() throws ClassNotFoundException, SQLException {
        Class.forName("com.mysql.jdbc.Driver");
        Connection c = DriverManager.getConnection("jdbc:mysql://localhost/springbook", "spring", "book");
        return c;
    }

}

위와같이 변경함으로, 이제 DB 종류 혹은 접속 정보가 변경되더라도 getConnection 메소드만 수정하여 문제를 해결할 수 있게 되었습니다.

만약, UserDao를 소스를 외부에 제공하기 위해서는 메소드 추출만으로는 유연한 코드가 될 수 없습니다.

UserDao를 사용하는 클라이언트 입장에서 자신들이 사용하는 DB와 접속 정보에 따라 UserDao 코드를 수정해야 하기 때문입니다.

좀 더 유연한 UserDao를 만들기 위해 이번에는 자바에서 제공되는 상속을 사용하여 코드를 리팩토링 하겠습니다.

public abstract class UserDao {

    public void add(User user) throws ClassNotFoundException, SQLException {
        Connection c = getConnection();
        PreparedStatement ps = c.prepareStatement("insert into users(id, name, password) values(?, ?, ?)");
        ps.setString(1, user.getId());
        ps.setString(2, user.getName());
        ps.setString(3, user.getPassword());

        ps.executeUpdate();

        ps.close();
        c.close();
    }

    public User get(String id) throws ClassNotFoundException, SQLException {
        Connection c = getConnection();
        PreparedStatement ps = c.prepareStatement("select * from users where id = ?");
        ps.setString(1, id);

        ResultSet rs = ps.executeQuery();
        rs.next();
        User user = new User();
        user.setId(rs.getString("id"));
        user.setName(rs.getString("name"));
        user.setPassword(rs.getString("password"));

        rs.close();
        ps.close();
        c.close();

        return user;
    }

    public abstract Connection getConnection() throws ClassNotFoundException, SQLException;
}

UserDao 클래스를 추상 클래스로, getConnection을 추상 메서드로 만들어 외부에서는 자신들이 사용하는 DB에 맞게 getConnection을 오버라이딩하여 사용할 수 있도록 만들었습니다.

위와 같인 슈퍼클래스에 기본적인 로직의 흐름을 만들고, 중간에 서브클래스가 제정의한 것을 사용하여 동작하도록 만드는 것이
템플릿 메소드 패턴입니다.

추가로, 위 예제에서는 Connection이라는 인터페이스를 통해 UserDao는 어떤 기능을 사용할지에 대한 관심만을 가지게 하였고.

서브 클래스들은 어떤 식으로 Connection 기능을 제공하는지에 관심을 가지도록 나누었습니다.

하지만, 위와 같은 코드도 문제점은 존재합니다. 바로 상속을 사용한 문제입니다.

자바는 기본적으로 다중 상속을 지원하지 않습니다.

때문에, UserDao의 서브 클래스는 UserDao가 아닌 클래스는 상속을 못받는 문제가 생깁니다.

4. DAO의 확장

위 getConnection은 DB 연결에 대한 관심으로 UserDao와는 관심이 다르기 때문에, 아예 별도의 클래스로 분리하겠습니다.

public class SimpleConnectionMaker {
    
    public Connection makeNewConnection() throws ClassNotFoundException, SQLException {
        Class.forName("com.mysql.jdbc.Driver");
        Connection c = DriverManager.getConnection("jdbc:mysql://localhost/springbook", "spring", "book");
        return c;
    }
}

public class UserDao {

    private SimpleConnectionMaker simpleConnectionMaker;

    public UserDao() {
        simpleConnectionMaker = new SimpleConnectionMaker();
    }

    public void add(User user) throws ClassNotFoundException, SQLException {
        Connection c = simpleConnectionMaker.makeNewConnection();
        PreparedStatement ps = c.prepareStatement("insert into users(id, name, password) values(?, ?, ?)");
        ps.setString(1, user.getId());
        ps.setString(2, user.getName());
        ps.setString(3, user.getPassword());

        ps.executeUpdate();

        ps.close();
        c.close();
    }

    public User get(String id) throws ClassNotFoundException, SQLException {
        Connection c = simpleConnectionMaker.makeNewConnection();
        PreparedStatement ps = c.prepareStatement("select * from users where id = ?");
        ps.setString(1, id);

        ResultSet rs = ps.executeQuery();
        rs.next();
        User user = new User();
        user.setId(rs.getString("id"));
        user.setName(rs.getString("name"));
        user.setPassword(rs.getString("password"));

        rs.close();
        ps.close();
        c.close();

        return user;
    }
}

관심사 분리를 적용하여 클래스 분리까지는 좋았습니다.

다만, 위 코드는 외부제공 시 가져야하는 connection에 대한 유연성 문제를 해결하지 못한 코드입니다.

이런 경우, 인터페이스를 통하여 2개의 관심사를 느슨하게 연결할 수 있습니다.

public interface ConnectionMaker {
    
    Connection makeConnection() throws ClassNotFoundException, SQLException;
}

public class UserDao {

    private ConnectionMaker connectionMaker;

    public UserDao(ConnectionMaker connectionMaker) {
        this.connectionMaker = connectionMaker;
    }

    public void add(User user) throws ClassNotFoundException, SQLException {
        Connection c = connectionMaker.makeConnection();
        PreparedStatement ps = c.prepareStatement("insert into users(id, name, password) values(?, ?, ?)");
        ps.setString(1, user.getId());
        ps.setString(2, user.getName());
        ps.setString(3, user.getPassword());

        ps.executeUpdate();

        ps.close();
        c.close();
    }

    public User get(String id) throws ClassNotFoundException, SQLException {
        Connection c = connectionMaker.makeConnection();
        PreparedStatement ps = c.prepareStatement("select * from users where id = ?");
        ps.setString(1, id);

        ResultSet rs = ps.executeQuery();
        rs.next();
        User user = new User();
        user.setId(rs.getString("id"));
        user.setName(rs.getString("name"));
        user.setPassword(rs.getString("password"));

        rs.close();
        ps.close();
        c.close();

        return user;
    }
}

ConnectionMaker라는 인터페이스를 하나 만들어, UserDao가 인스턴스 시 해당 인터페이스의 구현체를 전달받아 사용하도록 하는 코드로 변경하였습니다.

사실상, 위 코드는 UserDao를 사용하는 제3의 클라이언트가 런타임 시 UserDao와 ConnectionMaker와의 관계를 갖도록 책임을 위임한 코드입니다.

그렇다면, 클라이언트는 ConnectionMaker의 구현체를 만들어 new UserDao(connectionImpl); 같은 코드로 프로그래밍해야 합니다.

5. 제어의 역전(IoC)

일반적으로, 팩토리는 객체의 생성 방법을 결정하고 그렇게 만들어진 오브젝트를 돌려주는 일을 합니다.

위 예제에서는 제 3의 클라이언트가 팩토리 기능을 구현해야 하는 것입니다.

이것 또한, UserDao, ConnectionMaker와는 별개로 객체의 관계 설정이라는 관심사로 분리되어 별도 클래스로 추출이 가능합니다.

public class DaoFactory {
    
    public UserDao userDao() {
        ConnectionMaker connectionMaker = () -> {
            Class.forName("com.mysql.jdbc.Driver");
            Connection c = DriverManager.getConnection("jdbc:mysql://localhost/springbook", "spring", "book");
            return c;
        };
        UserDao userDao = new UserDao(connectionMaker);
        return userDao;
    }
}

DaoFactory를 분리했을 때 얻을 수 있는 장점은 아래와 같습니다.

어플리케이션의 컴포넌트 역할을 하는 오브젝트와 어플리케이션의 구조를 결정하는 오브젝트를 분리.

이러한, 객체간의 관계를 제 3의 클라이언트 혹은 Factory 클래스에게 위임하는것이 바로 객체지향에서의 Ioc(제어의 역전)입니다.

제어의 역전에서는 아래와 같은 기능들을 제공해야 합니다.

어플리케이션 컴포넌트의 생성과 관계설정
컴포넌트 사용
컴포넌트 생명주기 관리

6. 스프링의 IoC

이제 Ioc 역할인 DaoFactory를 스프링에서 사용하는 방식으로 변경하도록 하겠습니다.

스프링에서는 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 빈(bean)이라고 부릅니다.

또한, 빈은 스프링 컨테이너가 생성과 관계설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트를 가리키는 말입니다.

스프링에서는 DaoFactory와 같이 IoC 오브젝트를 빈 팩토리라고 부르며, 동시에 어플리케이션 컨테스트라고도 일컫습니다.

실제 코드상에서는 ApplicationContext는 BeanFactory의 서브 인터페이스입니다.

이제 위 DaoFactory의 기능을 스프링으로 변경하겠습니다.

@Configuration
public class DaoFactory {

    @Bean
    public UserDao userDao() {
        UserDao userDao = new UserDao(connectionMaker());
        return userDao;
    }
    
    @Bean
    public ConnectionMaker connectionMaker() {
        return () -> {
            Class.forName("com.mysql.jdbc.Driver");
            Connection c = DriverManager.getConnection("jdbc:mysql://localhost/springbook", "spring", "book");
            return c;
        };
    }
}

위 코드의 @Configuration과 @Bean은 아래와 같습니다.

@Configuration은 DaoFactory 클래스가 오브젝트 설정을 담당하는 클래스라는 것을 스프링이 인식할 수 있도록 하는 설정 표시.
@Bean은 오브젝트 생성을 담당하는 IoC용 메소드라는 표시

이제 DaoFactory를 설정정보로 사용하는 어플리케이션 컨텍스트는 아래와 같습니다.

public static void main(String[] args) {
    ApplicationContext context = new AnnotationConfigApplicationContext(DaoFactory.class);
    UserDao userDao = context.getBean("userDao", UserDao.class);
    ...
}

DaoFactory라는 설정정보를 담고있는 클래스를 통하여 어플리케이션 컨텍스트를 생성하였습니다.

이러한, 어플리케이션 컨텍스트는 getBean 메서드를 통해 설정정보 클래스에 정의한 오브젝트를 가져올 수 있습니다.

getBean 메서드에서 사용한 "userDao"는 가져올 빈 이름을 의미합니다.

이 이름은 DaoFactory에서 @Bean 어노테이션을 붙인 메서드 명이 자동적으로 UserDao 빈의 이름으로 등록되어 집니다.

굳이 이름을 통하여 빈을 가져와야 하는 이유는, 스프링에서는 동일 타입의 인스턴스들을 빈으로 등록할 수 있기 때문입니다.

어플리케이션 컨텍스트는 DaoFactory와는 다르게 어플리케이션 전체에 IoC를 적용하여 모든 오브젝트에 대한 생성과 관계설정을 담당하는 것을 알았습니다.

이러한 스프링의 어플리케이션 컨텍스트 장점은 아래와 같습니다.

클라이언트는 구체적인 팩토리 클래스를 알 필요가 없습니다.
어플리케이션 컨텍스트는 종합 IoC 서비스를 제공해줍니다.
어플리케이션 컨텍스트는 빈을 검색하는 다양한 방법을 제공합니다.

7. 싱글톤 레지스트리와 오브젝트 스코프

스프링 어플리케이션 컨텍스트는 bean을 저장하고 관리하는 IoC 컨테이너라고 했습니다.

이때, bean은 싱글톤으로서 하나의 객체를 생성하여 bean으로 등록하여 재사용합니다.

싱글톤으로 만들어 사용하는 이유로는 스프링이 서버에서 주로 사용되는 프레임워크이기 때문입니다.

계속적인 객체가 생성되어 리소스 낭비가 심해지는것을 방지하기 위해서 입니다.

자바 디자인 패턴 중 싱글톤 패턴과는 한개의 객체를 사용하도록 한다는 개념은 같지만 약간 사용성이 다릅니다.

자바 싱글톤 패턴은 아래와 같습니다.

public class UserDao {

    private static UserDao INSTANCE;

    private UserDao() {
    }

    public static synchronized UserDao getInstance() {
        if (INSTANCE == null) INSTANCE = new UserDao();
        return INSTANCE;
    }
}

스프링의 bean의 싱글톤은 아래와 같이 정의할 수 있습니다.

public class UserDao {

    private static UserDao INSTANCE;

    public UserDao() {
    }

    public static UserDao getInstance() {
        if (INSTANCE == null) INSTANCE = new UserDao();
        return INSTANCE;
    }
}

차이점으로는 아래와 같습니다.

생성자 = bean의 경우 private 생성자가 아니기 때문에, 객체 생성에 대한 제약이 있지 않습니다.
동기화 코드 = bean의 경우 synchronized 선언이 되어 있지 않습니다. 이는 synchronized로 인해 발생하는 성능이슈를 방지하기 위함입니다.

차이점에서 두번째인 동기화 코드로 인해 bean 사용시 유의해야 할 점이 있습니다.

그건 바로, stateful 방식의 bean이 아닌 stateless 방식으로 빈을 생성해야 한다는 것입니다.

이유는 stateful 방식으로 bean을 사용하면 멀티쓰레드 환경에서 동시접근으로 인해 정확한 상태를 가질 수 없기 때문입니다.

8. 의존관계 주입(DI)

스프링에서 제공하는 또 하나의 큰 기능을 말하라고 한다면 DI(Dependency Injection) 를 말할 수 있습니다.

DI는 말 그대로 의존관계 주입으로 위에서 DaoFactory가 UserDao와 ConnectionMaker간의 의존성 관계를 주입하는 것을 의미합니다.

의존관계에는 방향성이 존재합니다.

위 UserDao와 ConnectionMaker의 의존관계를 표현한다면 UserDao -> ConnectionMaker로 표현할 수 있으며,

UserDao는 ConnectionMaker에 의존하고 있다고 말할 수 있습니다.

즉, 이 경우 UserDao는 ConnectionMaker에 의존하고 있기 때문에, ConnectionMaker 변경에 영향을 받습니다.

하지만, ConnectionMaker는 UserDao 에 의존하고 있지 않기 때문에 UserDao 변경에 영향을 받지 않습니다.

스프링에서는 의존관계 주입을 3가지의 방법을 통해 정의할 수 있습니다.

어노테이션 - @Autowired를 사용
생성자 주입
setter 주입

위의 경우 UserDao는 생성자에 ConnectionMaker를 받고 있기 때문에 생성자 주입방식을 사용한 것을 알 수 있습니다.

스프링 Document에서는 DI 방식으로 생성자 주입을 권장하고 있습니다.
다만, 의존관계가 많은 클래스의 경우 생성자 코드가 커져 장황한 코드가 나올 수 있는 단점이 있습니다.
이는 lombok 과 같은 써드파티 라이브러리를 사용한다면 해결 가능합니다.

추가로 스프링은 DL(Dependency Lookup) 도 제공하고 있습니다.

DL은 의존관계 검색으로서 위에서 살펴본 getBean을 DL이라고 볼 수 있습니다.

DI는 객체간의 의존관계를 주입하기 위해 제어권을 스프링에게 넘겨야 하며, DI의 관련 객체들은 모두 bean으로 스프링 컨테이너에 등록되어야 합니다.

하지만 DL은 스프링 컨테이너에 등록된 bean을 검색하는 용도로,

DL을 사용하는 클래스는 bean으로 등록될 필요가 없다는 차이점을 가지고 있습니다.

9. 마무리

이번 포스팅에서는 오브젝트와 의존관계에 대해 간단한 소개와 설명을 했습니다.

다음에는 테스트에 대해 포스팅하겠습니다.

'Framework > Spring' 카테고리의 다른 글

(2) 테스트 (2)	2020.06.21

PREV 1 NEXT

geonyeongkim