1장에서 작성한 테스트의 특징
- 자바에서 가장 손쉽게 실행 가능한 main() 메서드 이용
- 테스트할 대상인 UserDao의 오브젝트를 가져와 메소드 호출
- 테스트에 사용할 입력값을 직접 코드에서 만들어 넣어줌
- 테스트의 결과를 콘솔에 출력
- 각 단계의 작업이 에러 없이 끝나면 콘솔에 성공 메시지로 출력
단위 테스트
- 웹단위 테스트의 문제점 : 모든 레이어의 기능을 다 만들고 나서야 테스트가 가능하다, 어디서 에러가 났는지 찾아내야 하는 수고도 필요하다 => 번거롭고 오류가 있을 때 빠르고 정확하게 대응하기 힘듦
- 작은 단위 테스트 : 외부 리소스에 의존하지 않는 단위테스트, 관심사의 분리 => 지속적인 개선과 점진적인 개발을 위한 테스트
- 자동수행 테스트코드 : 스스로 실행해주고 결과까지 알려주도록 자동화 => 자주 반복할 수 있어 테스트 효율적인 수행과 결과 관리
1장에서 작성한 테스트의 문제점
- 수동 확인 작업의 번거로움
- 실행 작업의 번거로움
JUnit
- 테스트 프레임워크
- 개발자가 만든 클래스에 대한 제어 권한을 넘겨받아 주도적으로 애플리케이션 흐름을 제어 ->
제어의 역전 - 기존
main()메서드 테스트는 제어권을 직접 갖는다는 의미 => 일반 메서드로 전환- 메서드를
public으로 선언 - 메서드에
@Test어노테이션 붙이기
- 메서드를
TDD
- 원칙 : 실패한 테스트를 성공시키기 위한 목적이 아닌 코드는 만들지 않는다
- 로드 존슨 : “항상 네거티브 테스트를 먼저 만들라”
- 테스트를 만들 때 부정적인 케이스를 먼저 만드는 습관을 들이는 게 좋다
- get()의 경우, 존재하지 않는 id가 주어졌을 때 예외적인 상황을 테스트해야 함 => 일반적인 개발 흐름 중 기능설계에 해당하는 부분을 테스트코드가 담당, 즉 코드로 된 설계문서
- TDD의 장점
- 테스트를 먼저 만들고 테스트가 성공하도록 하는 코드만 구현하기 때문에 테스트를 빼먹지 않고 꼼꼼하게 만들 수 있다
- 테스트를 작성하는 시간과 어플리케이션 코드를 작성하는 시간의 간격이 짧아진다 => 오류를 빨리 발견할 수 있다
- 매번 테스트가 성공하는 것을 보며 작성한 코드에 확신을 가질 수 있다.
픽스처
- 테스트를 수행하는 데 필요한 정보나 오브젝트
- 여러 테스트에서 반복적으로 사용되기 때문에 일반적으로 @Before 메소드 이용
DataSource Interface가 필요할까?
- 소프트웨어 개발에서 절대로 바뀌지 않는 것은 없다. 클래스 대신 인터페이스, new를 이용한 생성 대신 DI를 통한 주입
- 다른 차원의 서비스 기능 도입이 쉽다.
- 효율적인 테스트를 손쉽게 만들 수 있다
테스트 코드에 의한 DI
- 작은 단위를 독립적으로 테스트하는데 중요한 역할을 한다
-
@DirtiesContext- 테스트 메서드에서 애플리케이션 컨텍스트의 구성이나 상태를 변경한다는 것을 테스트 컨텍스트 프레임워크에 알려준다
- 테스트 메서드를 수행하고 나면 매번 새로운 애플리케이션 컨텍스트를 만들어 다음 테스트가 사용하게 해준다
- 매번 애플리케이션을 만드는 문제가 있음
컨테이너 없는 DI 테스트
- 사실 UserDao에서는 스프링 컨테이너를 동작하게 할 필요가 없다
- 필요한 오브젝트 생성과 관계설정을 테스트에서 직접해서 시간도 빨라지고 단순해진다
- 하지만, JUnit은 매번 새로운 테스트 오브젝트를 만들기 때문에 매번 새로운 UserDao 오브젝트가 만들어진다는 단점이 있음 (그래봤자 가벼운 오브젝트라 별 문제는 아님)
- DI 컨테이너나 프레임워크가 DI를 가능하게 해주는 것이 아니고 편리하게 사용하도록 해주는 것(비침투적 기술)
DI를 이용한 테스트 방법 선택
- 항상 스프링 컨테이너 없이 테스트할 수 있는 방법을 가장 우선적으로 고려
- 테스트 수행 속도가 가장 빠르고 테스트 자체가 간결
- 스프링의 설정을 이용한 DI 방법
- 여러 오브젝트와 복잡한 의존관계를 갖는 경우
- 컨텍스트에서 DI 받은 오브젝트에 다시 테스트코드로 수동 DI해서 테스트하는 방법
- 테스트 설정을 따로 만들었다고 해도 예외적인 의존관계를 강제로 구성해야 할 경우
- 테스트 메서드나 클래스에
@DirtiesContext붙이기