목차
2.1.1 테스트의 유용성
UserDaoTest() + main() 메소드를 이용한 add(), get() 메소드의 동작 확인 + 테스트가 있었으므로 다양한 방법으로 UserDao의 코드의 설계와 코드를 개선 + 테스트 : 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지를 확인 -> 만든 코드에 대한 확신
2.1.2 UserDaoTest의 특징
UserDaoTest
public class UserDaoTest {
public static void main(String[] args) throws ClassNotFoundException, SQLException{
ApplicationContext context = new GenericXmlApplicationContext("/applicationContext.xml");
UserDao dao = context.getBean("userDao", UserDao.class);
User user = new User();
user.setId("whiteship");
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() + "조회 성공");
}
}
- 손쉽게 이용 가능한 main() 메소드 이용
- 테스트 대상인 UserDao 오브젝트를 가져와 메소드를 호출
- 테스트에 사용할 입력 값(User 오브젝트)를 직접 코드에서 만들어 넣어준다.
- 결과를 콘솔에 출력
- 각 단계의 작업이 에러 없이 끝나면 성공 메세지를 출력
웹을 통한 DAO 테스트 방법의 문제점
일반적인 웹프로그램의 DAO 테스트 방법
- DAO를 만든다.
- 서비스 계층, MVC 프리젠테이션 계층 등 모든 입출력 기능을
대충이라도만든다. - 애플리케이션을 서버에 띄운 뒤, 웹 화면을 띄어 폼을 열고, 값을 입력한 뒤 버튼은 눌러 등록한다.
- 검색 폼 등을 이용하여 입력한 데이터를 가져올 수 있는지 테스트한다.
문제점
- DAO 뿐만 아니라 다른 모든 계층의 기능을 다 만들고 나서야 테스트가 가능하다.
- 테스트 중 에러가 발생하면 에러 발생 지점을 찾기가 어렵다.
작은 단위의 테스트
테스트하고자 하는 대상이 명확하다면 그 대상에만 집중하여야 한다.
- UserDaoTest : UserDao()가 잘 작동하는지에 대해서만 관심이 있다.
- 단위 테스트(Unit Test) : 작은 단위에 대해 테스트를 수행하는 것
- 단위 : 충분히 하나의 관심에 집중하여 효율적으로 테스트할 만한 범위(주관적)
- 일반적으로 단위는 작을수록 좋다.
- 통제할 수 없는 외부의 리소스에 의존하는 테스트는 단위 테스트가 아니라고 보기도 한다.
단위 테스트가 필요한 이유
- 개발자 스스로 자신의 코드에 대해 확신하기 위함
- 따라서 확인의 대상과 조건이 간단하고 명확할수록 좋다.
자동수행 테스트 코드
UserDaoTest : 테스트할 데이터가 코드를 통해 제공되고, 테스트 작업 역시 자동으로 실행된다.
- main() 이라는 가장 간단한 방법으로 테스트 전 과정이 자동으로 진행
- 테스트를 자주 수행해도 부담이 없다.
- 테스트는 자동으로 수행되도록 코드를 만드는 것이 중요
지속적인 개선과 점진적인 개발을 위한 테스트
테스트 코드 : DAO 코드를 개선할 수 있었던 일등 공신
- 초난감 DAO를 만들자마자 테스트 코드를 만들었기 때문에 조금씩 코드를 개선해나가는 것이 가능
- 테스트 없이 처음부터 스프링을 적용하고 XML 설정을 마친 후 검증을 시도하였다면 쏟아지는 에러메세지에 어디서부터 손을 대야 할 지 몰랐을지도 모른다.
2.1.3 UserDaoTest의 문제점
그럼에도 불구하고 현재의 UserDaoTest에는 몇가지 문제점이 있다.
- 수동 확인 작업의 번거로움
- 사람의 눈으로 확인하는 과정이 필요
- add()로 등록하고 get()으로 가져오지만, 둘의 값이 일치하는 지 테스트하지 않는다.
- 테스트의 진행은 자동이지만, 결과 확인 수동이다.
- 테스트의 양이 많아지고, 복잡해진다면 잘못된 결과를 확인하지 못 할 수도 있다.
- 실행 작업의 번거로움
- DAO가 많아지고 이에 Test 코드의 main() 메소드도 많아진다면 전체 기능을 테스트하기 위해 main() 메소드 역시 여러번 실행해야한다.
' Spring > 토비의 스프링 3.1' 카테고리의 다른 글
2.3 개발자를 위한 테스팅 프레임워크 JUnit (0) | 2019.01.14 |
---|---|
2.2 UserDaoTest 개선 (0) | 2019.01.11 |
2장. 테스트 (0) | 2019.01.11 |
1장. 오브젝트와 의존관계 (0) | 2019.01.11 |
1.9 정리 (0) | 2019.01.11 |