20180328 토비의 스프링 2장 : 테스트

테스트

• 수동 확인 작업의 번거로움
  자동으로 테스트되는 것이 아니다. 왜냐하면 사람이 테스트 결과를 최종적으로 확인하기 때문이다. 

• 실행 작업의 번거로움
  간단한 main() 메소드라고 하더라도 매번 그것을 실행시키는 것은 번거롭다. DAO가 수백 개가 되고 그에 대한 main() 메소드도 그만큼 만들어진다면 시간적으로 실행하고 결과 확인하는 수고가 많아진다. 체계적으로 테스트를 실행하고 그 결과를 확인하는 방법이 필요하다.

• 테스트 검증의 자동화
  모든 테스트에는 성공과 실패에 두가지 결과를 가지고 있다. 따라서 성공과 실패에 대해 우선적으로 if(){} else{} 구문으로 만들어준다.

자동화된 테스트를 위한 xUnit 프레임워크, JUnit

JUnit 설치하기.

@Before

@Test
- 해당 메소드에 대한 단위 테스트를 실시할 메소드를 지정.

@After

[ 참고링크 ]

[ 새내기 개발자의 JUnit 여행기 ]

[ Assert JUnit API ]

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

만들고자 하는 기능의 내용을 담고 있으면서 만들어진 코드를 검증도 해줄 수 있도록 테스트 코드를 먼저 만들고, 테스트를 성공하게 해주는 코드를 작성하는 방식의 개발 방법이 있다. 이를 테스트 주도 개발 방법론이라고 한다. 

미리미리 단위 테스트를 만들어서 코드를 검증하는 것이 좋다.

픽스처

테스트를 수행하는데 필요한 정보나 오브젝트를 픽스처(fixture) 라고 한다. 일반적으로 픽스처는 여러 테스트에서 반복적으로 사용되기 때문에 @Before 메소드를 이용해 생성해두면 편리.

@Autowired

스프링 DI에서 사용되는 아주 특별한 애노테이션이다. @Autowired를 이용해 애플리케이션 컨텍스트가 가지고 있는 빈을 DI 받을 수 있다면 getBean()을 사용하지 않아도 된다. 빈을 직접 DI 받을 수 있다. @Autowired 는 변수에 할당 가능한 타입을 가진 빈을 자동으로 찾는다. 여기서 @Autowired는 같은 타입의 빈이 두 개 이상 있는 경우에는 어떤 타입을 가져올지 결정할 수 없다.

DI는 객체 지향의 프로그래밍 스타일이다. DI 를 위해서 컨테이너가 필요한 것은 아니며, 컨테이너가 없더라도 구현될 수 있는 것이 DI 이다. DI 컨테이너 그리고 프레임워크는 DI를 편하게 적용하도록 도움을 주는 역할이 강하다.

정리

• 테스트는 자동화되어야 하며 정확하고 신속해야 한다.

• main() 메소드를 통한 검증이 아닌 JUnit 을 통한 검증 실시

• 테스트 결과는 일관성이 존재하여야 한다.

• @Before & @After 를 사용해서 테스트 메소드들의 공통 준비 작업과 정리 작업을 처리할 수 있다.