Sep. 2014 Youn-Hee Han http://link.koreatech.ac.kr Chapter 02. 테스트 Sep. 2014 Youn-Hee Han http://link.koreatech.ac.kr

2.1 UserDaoTest 다시 보기

2.1.1 테스트의 유용성 동일한 기능 수행 보장 테스트 1장에서 수행한 다양한 리펙토링 행위 UserDao 클래스를 각 책임에 따라 분리 인터페이스 도입 객체 팩토리를 통해 객체 생성 스프링의 DI 방식을 XML에 설정…. 위와 같은 변화를 주는 동안에도 동일간 기능이 수행됨을 어떻게 보장받을 수 있을까? 테스트 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지 확인하여 자신이 만든 코드에 확신을 가지도록 하는 작업

2.1.2 UserDaoTest의 특징 main() 메소드로 작성된 테스트 main() 메소드로 작성된 테스트의 내용 정리 리스트 2-1 참조 main() 메소드로 작성된 테스트의 내용 정리 main() 메소드 이용 테스트 대상인 UserDao 객체를 가져와 메소드 호출 테스트에 사용할 입력 값을 직접 코드에서 만들어 넣음 테스트 결과를 콘솔에 출력 각 단계의 작업이 에러 없이 끝나면 콘솔에 성공 메시지로 출력

2.1.2 UserDaoTest의 특징 웹을 통한 DAO 테스트 방법의 문제점 DAO 객체 뿐만 아니라 서비스 클래스, 컨트롤러, JSP 뷰 등 모든 레이어의 기능을 모두 만들어야 함 테스트 중에 에러가 발생할 시에 어느 곳에서 에러가 발생했는지 찾기가 어려움 하나의 테스트를 수행하는 데 참여하는 클래스와 코드가 많음 문제 원인의 다양함 DB 연결방법 오류 DAO 코드 자체의 오류 SQL 문법 오류 파라미터 값의 바인딩 오류 JSP 뷰에서의 코드 오류

2.1.2 UserDaoTest의 특징 작은 단위의 테스트 단위 테스트 (Unit Test) 테스트하고자 하는 대상이 명확하다면 그 대상에만 집중해서 테스트해야 함 테스트는 가능하면 작은 단위로 쪼개어서 집중해서 수행 관심사의 분리 원리 테스트 관심이 다르다면 테스트할 대상을 분리하고 집중해야 함 단위 테스트 (Unit Test) 작은 단위의 코드에 대해 테스트 수행 일반적으로 단위는 작을 수록 좋다.

2.1.2 UserDaoTest의 특징 DB 상태와 단위 테스트 개발자 테스트 (또는 프로그래머 테스트) 즉, 통제할 수 없는 외부의 리소스에 의존관계가 생기면 단위 테스트라고 볼 수 없음 개발자 테스트 (또는 프로그래머 테스트) 개발자가 만든 코드를 스스로 확인하는 테스트

2.1.2 UserDaoTest의 특징 자동수행 테스트 코드 테스트 코드의 분리 테스트할 데이터를 코드를 통해 직접 제공 테스트 작업 역시 코드를 통해 자동으로 실행 즉, main() 메소드 실행으로 테스트의 전 과정이 자동으로 진행 Self-contained!!! 개발자의 수작업을 최소화하고 코드 자체 내에 모든 테스트 내용이 포함되어야 한다. 반복 테스트 작업에 유리 테스트 코드의 분리 테스트 코드는 별도의 클래스로 분리하는 것 추천

2.1.2 UserDaoTest의 특징 지속적인 개선과 점진적인 개발을 위한 테스트 점진적 개발 방법 단위 테스트는 완성도 높은 객체지향적 코드로 발전시키는 과정의 필수 요소 테스트를 미리 만들어 놓지 않으면 리펙토링 과정이 그다지 미덥지 않을 수 있다. 마음이 불편해지면 개선 작업을 적당한 선에서 중지할 수 있음 테스트가 존재한다면 중간에 잘못 설계했거나 중요한 코드를 빼먹었을 경우 바로 확인 가능 점진적 개발 방법 1) 처음에는 단순한 방법으로 정상적으로 동작하는 코드 작성 2) 테스트 개발 3) 코드 개선  테스트 수행  코드 개선  테스트 수행  …

2.1.3 UserDaoTest의 문제점 UserDaoTest의 문제점 수동 확인 작업의 번거로움 실행 작업의 번거로움 콘솔에 나온 출력값 확인은 여전히 사람의 개입필요 실행 작업의 번거로움 만약 DAO가 수백 개가 되고 그에 대한 main() 메소드도 수백개라면 전체 기능을 테스트 하기 위해 main() 메소드를 수백번 실행해야 함

2.2 UserDaoTest 개선

2.2.1 테스트 검증의 자동화 테스트 결과의 검증 부분 수정 기존의 테스트 코드는 결과 값을 직접 사람의 눈으로 확인 개선 코드 기대하는 결과와 일치하는 경우 ‘테스트 성공’ 출력 기대하는 결과와 다른 경우 ‘테스트 실패’ 출력 테스트를 수행하면서 사람이 해야 할 일 단지 ‘테스트 성공’이라고 나오는지 확인하는 일

2.2.2 테스트의 효율적인 수행과 결과 관리 main() 메소드 테스트의 한계 JUnit 테스트로 전환 일정한 패턴을 지닌 테스트에 대해 반복적인 테스트 코드 작성의 지루함 테스트 결과를 종합적으로 한번에 확인 어려움 테스트가 실패한 곳을 빠르게 찾기 어려움 즉, 애플리케이션 규모가 커지고 테스트 개수가 많아졌을 때 이를 처리하는 것이 부담이 됨 JUnit 테스트로 전환 JUnit 프레임워크 제어의 역전 (IoC) 적용 개발자가 만든 클래스에 대한 여러 제어권을 넘겨받아 주도적으로 테스트 흐름을 제어

2.2.2 테스트의 효율적인 수행과 결과 관리 테스트 메소드 전환 main() 메소드에 있는 테스트 코드를 일반 메소드로 전환 메소드 이름에 테스트의 의도가 무엇인지 정확히 반영 static 키워드 제거 및 public 키워드 할당 @Test 애노테이션 할당

2.2.2 테스트의 효율적인 수행과 결과 관리 검증 코드 전환 assertThat 스태틱 메소드 matcher 스태틱 메소드 (is 메소드)

2.2.2 테스트의 효율적인 수행과 결과 관리 검증 코드 전환 전환 결과

2.2.2 테스트의 효율적인 수행과 결과 관리 JUnit 테스트 실행 성공 메시지 실패 메시지

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

2.3.1 JUnit 테스트 실행 방법 이클립스 IDE 활용 main() 메소드 작성 필요 없음 실행 방법 테스트 성공 화면 테스트 클래스 선택  이클립스 run 메뉴의 Run As  JUnit Test 선택 테스트 성공 화면 테스트 실패 화면

2.3.1 JUnit 테스트 실행 방법 이클립스 IDE 활용 한번에 여러 테스트 클래스 동시 실행 가능 단축키 테스트 클래스가 모여있는 특정 패키지 선택 Run As  JUnit Test 소스 폴더나 프로젝트 전체를 선택하여 실행 가능 단축키 Alt + Shift + X, then T (Window) Alt + Command + X, then T (Mac)

2.3.2 테스트 결과의 일관성 deleteAll() 및 getCount() 추가 deleteAll() 메소드 반복적 테스트에 대한 동일한 결과 보장 이를 위한 추가 메소드 addAndGet() 테스트를 수행하기 전에 이전 테스트가 등록했던 사용자 정보를 모두 삭제하여 초기화 하는 작업 필요 getCount() 메소드를 통해 테이블 내의 데이터 개수 확인 작업도 필요 deleteAll() 메소드

2.3.2 테스트 결과의 일관성 getCount() 메소드

2.3.2 테스트 결과의 일관성 새로운 메소드인 deleteAll()과 getCount()의 테스트

2.3.2 테스트 결과의 일관성 동일한 결과를 보장하는 테스트 어느 방법이 더 좋은가? 일관된 결과 보장 테스트 전 전체 테이블 내용 삭제 (추천) 테스트 후 전체 테이블 내용 삭제 테스트를 수행하다가 중간에 어떠한 이유로 예외가 발생하면 테이블 내용을 삭제하는 마지막 코드까지 갈 수 없다. 여러 테스트들이 동시에 존재할 때 테스트 순서가 바뀌면 삭제를 못한 체 테스트 할 수 있음 일관된 결과 보장 DB에 데이터가 남아 있는 등의 외부 환경에 영향을 받지 말아야 함 테스트를 실행하는 순서가 바뀌어도 결과가 보장되어야 함

2.3.3 포괄적인 테스트 다양한 상황의 테스트 필요 포괄적인 테스트를 위한 사전 준비 앞의 예에서는 getCount() 실행 결과가 0과 1만 테스트 한 두 가지 결과만 검증하고 끝내는 것은 위험 포괄적인 테스트를 위한 사전 준비 User객체 생성방법 추가

2.3.3 포괄적인 테스트 별도의 getCount() 테스트 [주의] 각 테스트의 순서와 상관없이 두 테스트 모두 통과

2.3.3 포괄적인 테스트 addAndGet() 테스트 보완 get()에 대한 테스트 보완 get()의 파라미터로 주어진 id에 해당하는 사용자를 올바르게 가져왔는지 테스트

2.3.3 포괄적인 테스트 get() 에외조건에 대한 테스트 테이블에 존재하지 않는 id와 함께 get() 호출 고려 null 리턴 예외 리턴( 추천) o.s.dao.EmptyResultDataAccessException 테스트 메소드 부터 추가

2.3.3 포괄적인 테스트 get() 에외조건에 대한 테스트 테스트를 성공시키기 위한 코드 UserDao 코드 수정

2.3.3 포괄적인 테스트 포괄적인 테스트 테스트의 종류 “항상 네거티브 테스트를 먼저 만들라“ - 스프링의 창시자 로드 존슨 성공 상황 (정상적인 상황)에 대한 테스트 실패 상황에 대한 테스트 “항상 네거티브 테스트를 먼저 만들라“ - 스프링의 창시자 로드 존슨 예외적인 상황을 빠트리지 않는 꼼꼼한 테스트 필요

2.3.4 테스트가 이끄는 개발 get() 메소드 예외 테스트 개발 순서 기능설계를 위한 테스트 실패할 상황을 예측하여 먼저 테스트 코드 개발 이후에 UserDao 코드 수정 기능설계를 위한 테스트 getUserFailure() 테스트 코드 분석

2.3.4 테스트가 이끄는 개발 기능설계를 위한 테스트 테스트 코드가 마치 잘 작성된 “기능 정의서/설계도" 역할을 함 개발하고자 하는 기능에 대해 별도의 다른 문서가 아닌 테스트 코드 안에 개발 언어로 표현 가능 테스트의 역할 실제 기능 개발 이후에 자신이 설계한 대로 동작하는지 검증 테스트 주도 개발 (Test Driven Development, TDD) 테스트 우선 개발 (Test First Development) 테스트를 먼저 만들고 테스트가 개발을 이끌어가는 방식의 개발 개발자가 테스트를 만들어가면서 개발하는 방법이 주는 장점을 극대화한 방법 기본 원칙: “실패한 테스트를 성공시키기 위한 목적이 아닌 코드는 만들지 않는다.”

2.3.5 테스트 코드 개선 JUnit이 제공하는 방법을 활용한 테스트 코드 리팩토링 중복 코드의 제거 @Before 애노테이션 사용

2.3.5 테스트 코드 개선 Junit 프레임워크에서의 테스트 수행 수행 절차 1) 테스트 클래스에서 @Test가 붙은 테스트 메소드 및 @Before, @After 메소드를 모두 찾는다. 2) 테스트 클래스의 객체를 하나 만든다. 3) @Before가 붙은 메소드가 있으면 실행한다. 4) @Test가 붙은 메소드를 호출하고 테스트 결과를 저장한다. 5) @After가 붙은 메소드가 있으면 실행한다. 6) 나머지 @Test가 붙은 메소드들에 대해 2) ~ 5)과정을 반복한다. 7) 모든 테스트 결과를 종합하여 돌려준다. 주의 1] 각 @Test 메소드마다 별도의 객체 생성 주의 2] @Before/@After와 @Test간에 주고 받을 정보는 인스턴스 변수를 이용하여 전달 예 - dao 객체 (userDao)

2.3.5 테스트 코드 개선 Junit 프레임워크에서의 테스트 수행 수행 절차

2.3.5 테스트 코드 개선 픽스쳐 (fixture) 테스트를 수행하는 데 필요한 정보나 객체 여러 테스트 메소드에서 반복적으로 사용됨 일반적으로 픽스쳐 정보 생성은 @Before 메소드에서 수행 픽스쳐 정보를 사용하지 않는 @Test 메소드 (getUserFailure)가 있어도 추후를 대비하여 @Before에서 생성하여 인스턴스 변수로 남겨두는 것이 좋음