📃 토비 스프링 2장 정리

• main()로 작성된 테스트

public class UserDaoTest {
  public static void main(String[] args) throws SQLExption {
    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());
      Sysyem.out.println(user2.getName());
      System.out.println(user2.getPassword);

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

위 코드에서는 main() 메소드로 테스트를 진행한다는 것과 테스트 대상인 UserDao를 직접 혹출해서 사용한다는 점이 특징이다.

🖥 웹을 통한 DAO 테스트 방법의 문제점

서비스 클래스, 컨트롤러, JSP 뷰 등 모든 레이어의 기능을 다 만들고 나서야 테스트가 가능하다는 점이 가장 큰 문제다. 따라서 작은 단위로 테스트를 진행하는 것이 가장 좋음

이렇듯 작은 단위로 테스트를 하는 것이 단위테스트(Unit Test)라고 함. 일반적으로 단위는 작을수록 적음

🖊 UserDaoTest의 문제점

• 수동 확인 작업의 번거로움
  • 테스트 코드가 정상적으로 작동했다고 하더라도 set과 get의 결과가 일치하는지 눈으로 확인해야함.
  • 검증해야 하는 양이 많아지면 번거로워질수 밖엥 없음
• 실행 작업의 번거로움
  • 만약에 실행할 main()이 수백개라면 당연히 테스트를 하는 것만으로도 큰 부담이 된다. 따라서 만약에 전체 기능을 모두 테스트한 결과를 정리하는 것만으로도 제법 큰 작업이 될 수 있다. 그러므로 main() 메소드를 이용하는 방법보다 좀 더 편리하고 체계적으로 실행하고 그 결과를 확인하는 방법이 절실히 필요하다.

🔍 UserDaoTest 개선

테스트 검증의 자동화

모든 테스트의 결과는 성공과 실패이며 실패는 테스트가 진행하는 동안 에러가 발생해서 실패하는 것과 에러가 발생하진 않았지만, 기대한 것과 다르게 나오는 경우 2가지가 있다. 따라서 아래의 코드를 다음과 같이 코드를 작성하면 테스트 검증의 자동화를 어느 정도 해결할 수 있다.

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

↓

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

⚖️ 테스트의 효율적인 수행과 결과 관리

위와 같이 코드를 작성하는 것 만으로도 작업을 상당부분 효율적으로 진행할 수 있다. 하지만, 이러한 과정으로 인해 번거로운 일이 사라진 것은 아니다. 따라서 해당 부분을 좀 더 효율적으로 수행하기 위해 Junit(Framework)이라는 테스트 지원 도구가 있다.

Junit은 프레임워크이기 때문에 main() 메소드도 필요없고 오브젝트를 만들어서 실행시키는 코드도 필요없다. 따라서 기존의 main 메소드는 Junit에 적용하기 적합하지 않다. 그러므로 가장 먼저 할 일은 main() 메소드에 있던 테스트 코드를 일반 메소드로 옮겨야한다. 새롭게 만들 메소드는 Junit 프레임워크가 요구하는 2가지 조건을 따라야 한다.

1. 메소드가 public으로 선언되어야 한다.
2. 다른 하나는 메소드에 @Test라는 애노테이션을 추가해야한다.

junit 프레임워크에서 동작하도록 테스트 메소드를 재구성하면 다음과 같다.

import org.junit.Test;
// ...
public class UserDaoTest {
  
  @Test // → junit에게 테스트용 메소드임을 알려준다. 
  public void addAndGet() throws SQLException { // junit 테스트 메소드는 반드시 public으로 선언되어야 한다.
    ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
    UserDao dao = context.getBean("userDao", UserDao.class);
  }
}

이제 아까 작성했던 if else 구분을 junit의 버전으로 전환해보자. 이는 junit에서 assertThat이라는 스태틱 메소드를 이용해 변경할 수 있다.

assetThat(user2.getName(), is(user.getName()));

assertThat() 메소드는 첫 번째 파라미터의 값을 뒤에 나오는 매처(matcher)라고 불리는 조건으로 비교해서 일치하면 다음으로 넘어가고, 아니면 테스트가 실패하도록 만들어준다. is()는 매처의 일종으로 equals()로 비교해주는 기능을 가졌다.

같은 방법으로 2번째 if문도 다음과 같이 변경할 수 있다.

asserThat(user2.getPassword(), is(user.getPassword()))

중요한 것은 Junit은 예외가 발생하거나 assertThat()에서 실패하지 않고 테스트 메소드의 실행이 완료되면 테스트가 성공했다고 인식한다. “테스트 성공”이라는 메세지를 굳이 출력할 필요는 없다. Junit이 테스트를 실행하고 나면 테스트 결과를 다양한 방법으로 알려주기 때문이다.

이제 앞서 작성했던 UserDaoTest를 junit으로 변경한 코드는 아래와 같다.

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Asset.assertThat;
//...
public class UserDaoTest {
  @Test
  public void addAndGet() throws SQLException {
    ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");
    
    UserDao dao = context.getBean("userDao", UserDao.class);
    User user = new User();
    
    user.setId("gyumee");
    user.setName("박성철");
    user.setPassword("spring01");
    
    dao.add(user);
    
    User user2 = dao.get(user.getId());
    
    assertThat(user2,getName(), is(user.getName()));
    assertThat(user2.getPassword(), is(user.getPassword));
  }
}

코드만 만든다고 끝이 아니고 junit도 자바 코드임으로 어디선가 한번은 코드를 실행해줘야한다. 이를 위해서 어디에든 main() 메소드를 하나 추가하고 그 안에 JUnitCore 클래스의 main 메소드를 호출해주는 간단한 코드를 넣어주면 된다. 메소드 파라미터에는 @Test 테스트 메소드를 가진 클래스의 이름을 넣어준다. UserDaoTest를 실행할 테니 리스 2-6과 같이 springbook.user.dao.UserDaoTest라는 값을 넘겨준다.

import org.junit.runner.JUnitCore;
// ...
public static void main(String[] args) {
  JUnitCore.main("springbook.user.dao.UserDaoTest");
}

해당 main()를 실행하면 다음과 같은 메세지가 출력되며 다음과 같다.

JUnit version 4.7
Time: 0.578
OK 1 (test)

JUnit의 버전과 걸린 시간, 성공한 테스트 갯수가 출력된다. 이때 만약에 실패하면 실패한 메소드와 왜 실패했는지 알려준다.

📌 테스트 결과의 일관성

UserDaoTest를 작성했다고 하더라도 항상 테스트 결과가 일치하지 않는 경우가 발생했다면, 이전 테스트 때문에 DB에 등록된 중복 데이터가 있을 수 있다는 점이다. 가장 좋은 해결책은 addAndGet() 테스트를 마치고 나면 테스트가 등록한 사용자 정보를 삭제하고 테스트를 수행하기 이전 상태로 만들어 놓는 것이다. 그러면 테스트를 아무리 반복하여 실행해도 같은 결과를 얻을 수 있고, 이러한 결과를 얻어야 제대로 된 테스트 코드를 작성했다 볼 수 있다.

따라서 일관성 있는 테스트 결과를 보장하기 위해 UserDaoTest에 새로운 기능을 추가해준다.

• deleteAll(), getCount()

  • deleteAll() : USER 테이블의 모든 레코드를 삭제해주는 간단한 기능이 있다. UserDao 클래스에 메소드를 추가하자.

  public void deleteAll() throws SQLException {
    connection c = dataSource.getConnection();
      
    PrepareStatement ps = c.prepareStatement("delete from users");
    ps.executeUpdate();
      
    ps.close();
    c.close();
  }
  

  add()와 비슷한데 파라미터 바인딩이 없으므로 더 단순하다.

  • getCount(): 두 번째로 추가할 것은 getCount()로 USER 테이블의 레코드 개수를 돌려준다. 이는 get 메소드와 비슷한 구조이다.

  public int getCount() throws SQLException {
  	Connection c = dataSoutce.getConnection();
      
    PrepareStatement 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;
  }
  

addAndGet()테스트의 불편한 점은 실행 전에 수동으로 USER 테이블의 내용을 모두 삭제해줘야 하는 것이었다. 하지만 deleteAll()을 사용하면 테이블의 모든 내용을 삭제할 수 있으니 테스트가 시작될 때 실행하면 좋을 것이다. 만약 잘 작동하면 테스트 때마다 일일이 테이블을 삭제하지 않아도 괜찮을 것이다. 하지만 deleteAll()자체도 검증되지 않았다는 것을 감안하면 무턱대고 테스트에 적용하기에는 부담스럽다. 따라서 getCount()도 함께 적용해보자. 근데 여기서 또 문제가 getCount()도 검증되지는 않았다. 그래서 getCount()에 대한 검증 작업을 하나 더 추가한다. 물론 이 모든 코드는 addAndGet()메소드에 추가한다.

@Test
public void addAndGet() throws SQLException{
  //...
  dao.deleteAll();
  assertThat(dao.getCount(), is(0));
  
  User user = new User();
  user.setId("gyumee");
  user.setName("박성철");
  user.setPassword("springno01");
  
  dao.add(user);
  assertThat(dao.getCount(), is(1));
  
  User user2 = dao.get(user.getId());
  
  assertThat(user2.getName(), is(user.getName()));
  assertThat(user2.getPassword(), is(user.getPassword()));
}

Junit은 하나의 클래스 안에 여러 개의 테스트 메소드가 들어가는 것을 허용한다. @Test가 붙어 있고 public 접근자가 있으며 리턴 값이 void형이고 파라미터가 없다는 조건을 지키기만 하면 된다.

테스트를 만들기 전에 User 클래스에 한 번에 모든 정보를 넣을 수 있도록 초기화가 가능한 생성자를 추가한다. User 오브젝트를 여러 번 만들고 값을 넣어햐 하니, 한 번에 설정 가능한 생성자를 만들어두면 편리하다.

public User(String id, String name, String password) {
  this.id = id;
  this.name = name;
  this.password = password;
}

public User() { // → 자바빈의 규약을 따르는 클래스에 생성자를
  							// 명시적으로 추가했을 때는 파라미터가 없는 디폴트 생성자도 함께
  							// 정의해주는 것을 잊지말자.
}

위를 이용하면 addAndGet() 테스트의 코드도 다음과 같이 간략히 수정할 수 있다.

UserDao dao = context.getBean("userDao", UserDao.class);
User user = new User("gyumee", "박성철", "springno01");

이러한 방식으로 getCount()에 대한 테스트 메소드를 작성한다.

@Test
public void count() throws SQLException {
  ApplicationContext context = new GenericXmlApplicaiotnConext("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();
  assertThat(dao.getCount(), is(0));
  
  dao.add(user1);
  assertThat(dao.getCount(), is(1));
  
  dao.add(user2);
  assertThat(dao.getCount(), is(2));
  
  dao.add(user3);
  assertThat(dao.getCount(), is(3));
}

그런데 get()이 파라미터로 주어진 id에 해당하는 사용자를 가져온 것인지, 아니면 그냥 아무거나 가져온 것인지 테스트에서 검증하지 못했다. 해당 부분은 User를 하나 더 추가해서 id를 정확히 가져왔는지 확인해보므로서 addAndGet()를 보완할 수 있다.

@Test
public void addAndGet() throws SQLException {
  // ...
  
  UserDao dao = context.getBean("userDao", UserDao.class);
  user user1 = new User("gyumee", "박성철", "springno1");
  user user2 = new User("leegw700", "이길원", "springno2");
  
  dao.deleteAll();
  asserThat(dao.getCount(), is(0));
  
  dao.add(user1);
  dao.add(user2);
  assertThat(dao.getCount(), is(2));
  
  User userget1 = dao.get(user1.getId());
  assertThat(userget1.getName(), is(user1.getName()));
  assertThat(userget1.getPassword(), is(user1.getPassword()));
  
  User userget2 = dao.get(user2.getId());
  assertThat(userget2.getName(), is(user2.getName()));
  assertThat(userget2.getPassword(), is(user2.getPassword()));
}

이렇게 하면 id 값에 접근한 user 정보와 저장한 user 정보와 동일함을 확인하므로써 get()에 대해 신뢰를 얻고 테스트 코드를 작성할 수 있다.

근데 만약에 id로 접근했는데, 데이터가 없다면 어떻게 될까? 이럴 때는 2가지 방법으로 해결할 수 있다.

1. null과 같은 특별한 값을 리턴
2. id 정보를 찾을 수 없다고 리턴

각각의 장단이 있는데, 일단 2번의 방법을 알아보자.

일단 스프링에서 EmptyResultDataAccessException은 예외 클래스이다. 이를 이용하면 UserDao에서 쿼리를 실행해 가져온 결과에 아무것도 없을 때 예외를 던지도록 만들 수 있다. 여기서 가장 큰 문제는 이러한 테스트를 어떻게 작성해야 하는가? 이다. 왜냐하면, 테스트 중에 예외가 던져지면 테스트 메소드의 실행은 중단되고 테스트는 실패하기 때문이다. 근데 이번에는 반대로 예외가 던져지지 않는다고 생각해보자 정상적으로 테스트가 끝나면 이 또한 예외를 알기위한 테스트는 실패한 것 아닌가? 즉 예외 발생 여부는 메소드를 실행해서 리턴 값을 비교하는 방법으로는 확인할 수 없다는 것이다. 다시 말해 assertThat()으로는 확인이 불가능하다. 말이 길어졌는데, 이 부분을 Junit에서 특별한 방법으로 해결할 수 있다. 일단 테스트 메소드를 하나 더 추가하자. 방법은 간단하다.

1. 데이터를 모두 지운다.
2. 존재하지 않는 id로 get()을 호출한다.
3. 이때 EmptyResultAccessException이 던져지면 성공이고 아니면 실패다.

@Test(expected=EmptyResultDataAccessException.class) // → 테스트 중에 발생한 것으로 기대하는 예외 클래스를 지정
public void getUserFailure() Throws SQLException {
  ApplicationContext context = new GenericXmlApplicationContext("applicationContext");
  
  UserDao dao = context.getBean('userDao', UserDao.class);
  dao.deleteAll();
  assertThat(dao.getCount(), is(0));
  
  dao.get("unknown_id");
}

Test코드는 간단하다. 모든 User 데이터를 지우고 존재하지 않는 id로 get() 메소드를 실행하는 게 전부다. 이 테스트에서 중요한 것은 @Test 애노테이션의 expected 엘리멘트다. excepted는 테스트 메소드 실행 중에 발생하리라 기대하는 예외 클래스를 넣어주면 된다.

@Test에 expected를 추가해놓으면, 보통의 테스트와는 반대로 정상적으로 테스트 메소드를 마치면 테스트가 실패하고 expected에서 지정한 예외가 던져지면 테스트가 성공한다.

반드시 예외가 발생해야하는 경우 유용하게 쓸 수 있으니 기억하자. 근데 웃긴건 위에 코드 돌리면 실패한다. 왜냐면 get()메소드에서 쿼리 결과의 첫 번째 행을 가져오게 하는 rs.next()를 실행할 때 가져올 로우가 없다는 SQLException이 발생할 것이고 이건 당연하다 아직 UserDao에 손 안댔다.

위코드를 성공시키기 위해서는 get메소드를 따로 만들어준다. get에서 데이터가 없으면 EmptyResultDataAccessException을 던지면 된다.

public User get(String id) throws SQLException {
  // ... 
  ResultSet rs = ps.executeQuery();
  
  User user = null; // → User는 null 상태로 초기화해놓는다.
  if(rs.next()) {
    user = new User();
    user.setId(rs.getSring("id"));
    user.setName(rs.getString('name'));
    user.setPassword(rs.getString("password")); // id를 조건으로 한 쿼리의 결과가 있으면 User
    // 오브젝트를 만들고 값을 준다.
  }
  rs.close();
  ps.close();
  c. close();
  
  if (user == null) throw new EmptyResultDataAccessException(1);
  
  return user;
}

위의 코드는 정상적으로 작성되는 것을 알 수 있다.

지금 우리가 진행한 상황을 돌이켜보면 한 가지 재밌는 점을 찾을 수 있는데, 이건 먼저 기능 코드를 작성하지 않고 테스트 코드를 작성 후 기능 코드를 수정했다는 점이다. 이러한 과정을 TDD(Test Driven Development)또는 TFD(Test First Development)라고 한다.

이러한 부분을 보았을 때 TDD는 매우 중요한 개발 방식이라는 것을 잊지말자.

또한 test코드도 리펙토링의 대상이된다. 좀더 이해하기 쉽고 가독성이 좋아하는 코드로 변경하는 과정은 기능 부문뿐만 아니라 테스트 코드도 필요하다.

우리는 지금까지 3개의 테스트 코드를 작성했다. UserDaoTest코드를 잘 상펴보면 기계적으로 반복되는 부분이 눈에 띈다.

ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");
User dap = context.getBean("userDao",UserDao.class);

이 부분을 별도의 메소드로 옮기고 해당 부분 위에 @Before 애노테이션을 적어주면 된다. 이러한 메소드를 setUp()이라고 한다면 다음과 같이 UserDaoTest의 코드가 변경되고 더 깔끔한 느낌을 받을 수 있다. 물론 해당 부분은 Junit에서 제공하는 기능이다.

import org.junit.Before;
// ...
public class UserDaoTest {
  private UserDao dao;
  
  @Before
  public void setUp() {
    ApplicationContext context = new GenericXmlApplicationContextx("applicationContext.xml");
    this.dao = context.getBean("UserDao", UserDao.class);
  }
  // ...
  @Test
  public void addAndGet() throws SQLException {
    // ...
  }
  
  @Test
  public void count() throws SQLException {
    // ...
  }
  
  @Test(expected=EmptyResultDataAccessException.class)
  public void getUserFailure() throws SQLException {
    // ...
  }
}

물론 위의 코드를 이해하기 위해서는 junit의 동작 방식을 좀 알아봐야한다.

1. 테스트 클래스에 @Test가 붙은 public이고 void형이며 파라미터가 없는 테스트 메소드를 모두 찾는다.
2. 테스트 클래스의 오브젝트를 하나 만든다.
3. @Before가 붙은 메소드가 있으면 실행한다.
4. @Test가 붙은 메소드를 하나 호출하고 테스트 결과를 저장해둔다.
5. @After가 붙은 메소드가 있으면 실행한다.
6. 나머지 테스트 메소드에 대해 2~5번을 반복한다.
7. 모든 테스트의 결과를 종합해서 돌려준다.

실제로는 이보다 더 복잡하다고 한다. 대략적으로 junit 테스트는 위의 7단계를 거쳐서 진행된다고 볼 수 있다.

근데 여기서 Before와 After가 도대체 뭐냐? 생각이 들 수 있는데, 테스트 하기 전에 실행하는 것을 Before, 테스트가 실행된 후 실행하는 것을 After라고 볼 수 있다.

여기서 Junit은 테스트를 실행할 때마다 새로운 오브젝트가 생성되게끔 만들어져 있다. 이유는 각 테스트가 독립적으로 실행됨을 확실히 보장하기 위해서다. 물론 경우에 따라서 효율적으로 코드를 작성할 수도 있으며 공통적인 특성을 지닌 테스트 메소드를 모아서 별도의 테스트 클래스로 만드는 방법도 생각해볼 수 있다.

테스트를 수행하는 데 필요한 정보나 오브젝트를 픽스처(fixture)라고 한다. 일반적으로 픽스처는 여러 테스트에서 반복적으로 사용되기 때문에 @Before 메소드를 이용해 생성해주면 편리하다. UserDaoTest에서는 dao가 픽스처이다.

public class UserDaoTest{
  private UserDao dao;
  private User user1;
  private User user2;
  private User user3;
	
  @Before
  public void setUp() {
    //...
    this.user1 = new User("gyumee", "박성철", "springno1");
    this.user2 = new User("leegw700", "이길원", "springno2");
    this.user3 = new User("bumjin", "박범진", "springno3");
  }
  // ...
}

📌 침투적 기술과 비침투적 기술

침투적 기술은 기술을 적용했을 때 애플리케이션 코드에 기술 관련 API가 등장하거나 특정 인터페이스나 클래스를 사용하도록 강제하는 기술을 말한다. 침투적 기술을 사용하면 애플리케이션 코드가 해당 기술에 종속되는 결과를 가져온다.

비침투적 기술은 애플리케이션 로직을 담은 코드에 아무런 영향을 주지 않고 적용이 가능하다. 따라서 기술에 종속적이지 않은 순수한 코드를 유지할 수 있게 해준다. 스프링은 이런 비침투적인 기술의 대표적인 예이다. (컨테이너 없는 DI테스트가 가능하기 때문에)

📌 동등분할과 경계값 분석

• 동등분할
  • 같은 결과를 내는 값의 범위를 구분해서 각 대표 값으로 테스트를 하는 방법을 말한다. 어떤 작업의 결과 true, false 또는 예외 발생 세 가지라면 각 결과를 내는 입력 값이나 상황의 조합을 만들어 모든 경우에 대한 테스트를 해보는 것이 좋다.
• 경계값 분석
  • 에러는 동등분할 범위의 경계에서 주로 많이 발생한다는 특징을 이용해서 경계의 근처에 있는 값을 이용해 테스트 하는 방법이다. 보통 숫자의 입력 값인 경우 0이나 그 주변 값 또는 정수의 최대값, 최소값 등으로 테스트해보면 도움이 될 때가 많다.