토비의 스프링 요약 (ch2 - 테스트)

토비의 스프링 요약 (ch2 - 테스트)

---

[ 2.1 UserDaoTest 다시보기 ]

문제점

• main()에서 테스트 수행
• UserDao를 가지고와서 직접 호출
• 테스트할 값 직접 입력
• 테스트 결과는 콘솔로…

작은단위의 테스트 (Unit Test)

• 테스트 대상을 쪼개서 분석하고자 하는 대상에만 집중
• ‘관심사의 분리’라는 원리가 테스트에도 적용
• 기능에 따라 웹 인터페이스, 서버 등의 기능과 분리
• 개발자가 의도한대로 동작하는지 스스로 빨리 확인하기 위해!

---

[ 2.2 UserDaoTest 개선 ]

자동으로 수행되게!

• 테스트 결과를 콘솔창으로 출력하기 때문에 개발자가 눈으로 확인하는 절차를 줄여야함.

효율적인수행과 결과관리

• main()으로 테스트 : 규모가 커지면 부담… -> JUnit
• JUnit이 개발자가만든 코드를 실행 -> IoC의 동작원리
• JUnit테스트 프레임워크가 수행해주는 조건
  • 1. 메소드가 public 으로 선언
  • 1. @Test 라는 애노테이션 붙이기
• 검증코드의 전환

//main에서 테스트하던 UserDaoTest
if(!user.getName().equals(user3.getName())){
	System.out.println("테스트 실패 (name)");
}

//JUnit으로 개선된 코드
//is() : .equals()의 역할을 대신함
assertThat(user2.getName(), is(uiser.getName()));

---

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

테스트실행

• 다양한 IDE가 지원함 (이하 이클립스 기준)
• Run As - JUnit Test 로 한번에 실행가능
• Alt+Shift+x , t
• Ant, Maven같은 빌드 툴, 슼므립트 사용가능

테스트의 일관성

• 반복되어도 항상 같은 결과가 나와야함 (일관성)
• DB검사의 경우 deleteAll()과 같은 기능을 통해 확인가능 - deleteAll()도 테스트해야함

에러 테스트

• 발생할 것으로 기대하는 예외 클래스 지정.( 예외 발생 안하면 테스트 실패)

//expected 라는 문구는, 정상수행시 fail하게 만든다!
@Test (expected = EmptyResultDataAccessException.class)

• 작성하는 코드에는 예외 클래스로 던지게 만든다,

if(user == null) throw new EmptyResultDataAccessException(1);

• 성공하는 테스트만 만들지말고, 실패하는 경우도 생각하자!
  • 내pc에는 되는데,.,,,
  • 항상 부정적인 테스트먼저 만들어 보자

테스트 주도 개발 (TDD - Test Driven Development)

• 테스트 우선개발 (Test First Development) 이라고도 함.
• 테스트 조건을 하나의 기능 정의서 처럼 생각함.
• 테스트를 성공시키기위한 목적이 아닌 코드는 작성하지 않음.
• 빠른 피드백과 확신
• 작업의 주기가 짧아진다 (개발-테스트-원인파악-…)

테스트코드 최적화

• 중복된 코드는 하나의 함수로 분리한다(ex. db 연결)
• @Before 같은 애노테이션을 적극 활용
• JUnit의 동작방식

1. @Test, public, void, 파라미터없는것을 찾음
2. 테스트 클래스의 오브젝트 만듬
3. @Before를 수행
4. @Test 를 호출하고 저장
5. @After 수행
6. 2~5반복
7. 결과를 보여줌

• 픽스처 fixture
  • 반복적으로 사용되는 데이터들 ex. DB에 넣기위한 user데이터들
  • private로 변수를 선언하고 @Before에서 초기화 하여 중복 제거

[ 2.4 스프링 테스트 적용 ]

출처 : 토비의 스프링 3.1 vol1. - 이일민 지음