테스트
변화에 대응하는 전략
-
IoC/DI
-
테스트 기술 (만들어진 코드를 확신할 수 있게 해주고, 변화에 대응하는 자신감을 줌)
테스트를 할 때는 작은 단위로 테스트해야한다. 여러 단위가 합쳐지면 어느 부분에서 오류가 생겼는지 제대로 확인하기 어렵다.
테스트에서도 관심사의 분리가 필요하다. 오로지 관심있는 역할에 대해서만, 작은 단위로 테스트해야한다. 이를 단위 테스트 (unit test)라고 부른다.
테스트를 할 때는 성공, 실패에만 집중해서 코드를 자동화 한다. 객체 자체를 출력하기 보다는 객체 값과 예측 값이 일치하는지 등으로 성공과 실패에 대한
출력을 하게 한다.
만들어진 코드의 기능을 모두 점검할 수 있는 포괄적인 테스트를 만든다면, 수정에 자신감을 얻을 수 있을 것이다. (xUnit 프레임워크 - 켄트 백, "테스트는
개발자가 마음 편하게 잠자리에 들 수 있게 해주는 것")
보다 편리하게 테스트를 수행하고 결과를 확인할 수 있게 JUnit 프레임워크를 사용한다.
JUnit 테스트를 이용하기 위해서는 main()을 통한 테스트가 아닌 테스트 메소드를 만들어주고 @Test 어노테이션과 public 접근 제어자가 필요하다.
테스트를 진행할 때 주의할 점은, 객체에 저장된 정보를 테스트가 끝나고 지워주는 것이다.
그리고 개발자는 성공하는 테스트만 만드는 경우도 있는데, 스프링의 창시자 로드 존슨은 "항상 네거티브 테스트를 먼저 만들라"라고 조언한다.
테스트가 이끄는 개발
실제 코드를 먼저 작성하기 보다 테스트 코드를 작성하고 이를 다듬어가는 방식으로 테스트를 조건, 행위, 결과로 구분해 작성하여 개발한다면,
테스트의 성공이 코드 구현과 테스트를 한번에 작업할 수 있게 된다.
테스트 주도 개발 (TDD)
만들고자 하는 기능의 내용을 담고 있으면서 검증도 가능할 테스트 코드를 먼저 만들고, 테스트를 성공하게 해주는 코드를 작성하는 방식의 개발 방법을
테스트 주도 개발, Test Driven Development라고 한다. 이에 기본 원칙은 "실패한 테스트를 성공시키기 위한 목적이 아닌 코드는 만들지 않는다."이다.
- 픽스처, 테스트를 수행하는데 필요한 정보나 오브젝트
스프링 테스트 적용
순수 자바 코드만을 사용해 테스트하는 것이 좋고, 매 테스트마다 새로운 독립적인 오브젝트를 만들어 테스트하는 것이 원칙이지만,
애플리케이션 컨텍스트의 경우 매 테스트마다 생성될 경우에 너무 많은 자원과 시간이 소요될 수 도 있다. 이럴 경우 애플리케이션 컨텍스트가
전체 테스트에서 공유되게 할 수 있다. 애플리케이션 컨텍스트는 초기화되고 나면 내부의 상태가 바뀌는 일은 거의 없고, 빈은 싱글톤으로 만들었기 때문에ㅔ
상태를 갖지 않는다. 하지만 이럴 경우 차라리 스프링이 제공하는 테스트 컨텍스트 프레임워크를 사용하는 것이 더 편리하다.
테스트에서 DataSource 인터페이스를 구현할 때, SingleConnectionDataSource를 사용하는 것이 좋다. DB커넥션을 하나만 만들어주고 계속 사용하기 때문에
가장 빠르다.
또한 테스트시, 동등분할이나 경계값 분석을 통해 테스트 기법은 매우 중요하다.
DI를 이용한 테스트 방법 선택
-
스프링 컨테이너 없이 테스트
- 가장 빠르고 테스트가 간결
- 가장 먼저 고려해야한다.
-
복잡한 의존관계를 가진 오브젝트 테스트
- 별도의 테스트용 설정파일을 만들어 테스트
-
예외적인 의존관계를 강제로 구성이 필요한 테스트
- DI 받은 오브젝트에 다시 테스트코드로 수동 DI
- 테스트 메소드나 클래스에
@DirtiesContext(애플리케이션 컨텍스트의 상태를 변경)
