티스토리 뷰

Study/JUnit

단위테스트 작성 방법 분석, TDD 관련 정리

dev ms 2016. 8. 22. 14:47

junit을 이용하여 단위 테스트를 작성하여 현재 개발된 애플리케이션의 동작이 정상적으로 구동 되는지 확인할 수 있고, Meven 등으로 Build 시에도 단위 테스트가 먼저 작동된 후 Build 됨으로 현재 변경한 내용들이 기존 동작에 영향을 미치는지 확인 할 수 있다.

필요 라이브러리

<dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.11</version>
   <scope>test</scope>
</dependency>
<dependency>
   <groupId>org.mockito</groupId>
   <artifactId>mockito-all</artifactId>
   <version>1.9.5</version>
   <scope>test</scope>
</dependency>
<dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-test</artifactId>
   <version>3.2.3.RELEASE</version>
   <scope>test</scope>
</dependency>

스프링 테스트하기 위해 @RunWith로 SpringJUnit4ClassRunner를 사용해 spring-test를 확장한다.

@SpringApplicationConfiguration은 스프링을 사용하기 위해 설정한 설정 클래스를 지정하는 것인데, github에 소스를 보면 알겠지만 spring-boot를 사용했기 때문에 class(javaConfig)를 설정한 것이다. xml로 설정해도 마찬가지로 @SpringApplicationConfiguration을 사용한다.

프로젝트 구조가 나뉘어져 있는 상태여도

@SpringApplicationConfiguration(classes = {}) 를 이용하여 각 Config.java 파일들을 추가해주면 된다.

@WebAppConfiguration 은 다음과 같다.

클래스 레벨의 어노테이션으로 선언할 수 있다.

ApplicationContext에 WebApplicationContext를 통합적으로 load시켜준다.

원문

@WebAppConfiguration is a class-level annotation that is used to declare that the ApplicationContext loaded for an integration test should be a WebApplicationContext.

현재 Spring security OAuth 쪽으로 Token 발급을 하고 있었는데, 기존 JUnit Test로는 토큰 발급이 불가능했다.

정확하지는 않지만 SpringSecurity쪽 자원을 얻을려면 Spring SecurityFilterChain을 추가하여 MockMvc에 적용시켜줘야 정상 작동 하는 것 같다.

슬라이드에서 제공해주는 팁은 좋은 것 같다 -_-;;

jUnit annotation list

@Before

@BeforeClass

@After

@AfterClass

@Test

@Ignore

@Test(timeout=500)

@Test(expected=IllegalArgumentException.class)

단위테스트 순서 정렬방법

실행시 작성한 순서대로 단위 테스트가 동작하지 않는다 따라서 @FixMethodOrder 어노테이션을 이용해서 옵션을 설정해 준다.

@FixMethodOrder는 3가지 정렬 옵션을 가지고 있습니다.

속성	설명
MethodSorters.DEFAULT	HashCode를 기반으로 순서가 결정되기 때문에 사용자가 예측하기 힘듭니다.
MethodSorters.JVM	JVM에서 리턴되는 순으로 실행됩니다. 때에 따라서 실행시 변경됩니다.
MethodSorters.NAME_ASCENDING	메소드 명을 오름차순으로 정렬한 순서대로 실행됩니다.

RestTemplate를 이용한 테스트 작성

REST Service를 사용하기 위한 Template이다.

HTTP Method에 따라 메소드를 제공한다.

HTTP Method	RestTemplate methods
DELETE	delete
GET	getForObject
GET	getForEntity
HEAD	headForHeaders
OPTIONS	optionsForAllow
POST	postForLocation
POST	postForObject
PUT	put
any	exchange
any	execute

소스링크

https://github.com/audtjddld/angularjs-springboot-jpa-example/blob/changeProcess/demo2/src/test/java/com/example/restapi/RemoteRestAPITest.java

참고 사이트

https://gist.github.com/keesun/4603235

http://www.mkyong.com/java/json-simple-example-read-and-write-json/

http://sooin01.tistory.com/entry/RestTemplate-%EC%82%AC%EC%9A%A9%EB%B2%95

JUnit Test Suite 작성

단위테스트 작성 뒤 작성한 단위테스트를 전체적으로 테스트 할 수 있도록 Test Suite를 작성한다.

만드는 방법은 간단하다.

AllTests.java 라는 클래스가 생성되고 실행하게되면

위와 같이 단위테스트들이 한꺼번에 실행된다.

테스트 주도 개발 (Test Driven Deveopment, TDD)

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

테스트 우선 개발 (Test First Development) 라고도 한다.

TDD는 개발자가 테스트를 만들어가며 개발하는 방법이 주는 장점을 극대화한 방법이라고 볼 수 있다.

개발자들이 정신없이 개발을 하다 보면 사이사이 테스트를 만들어서 코드를 점검할 타이밍을 놓치는 경우가 많다. 빨리 기능을 완성하고 싶은 욕구 때문 일 수도 있고, 한번 집중하면 정신없이 빠져드는 습성 때문이기도 하다.

문제는 코드를 만들고 나서 시간이 많이 지나면 테스트를 만들기가 귀찮아진다는 점이다.

또, 작성한 코드가 많기 때문에 무엇을 테스트해야 할지 막막할 수도 있다. 결국 테스트 작성은 자꾸 뒷전으로 밀려나거나 점점 더 성의 없는 테스트를 만들게 될지도 모른다.

TDD는 아예 테스트를 먼저 만들고 그 테스트가 성공하도록 하는 코드만 만드는 식으로 진행하기 때문에 테스트를 빼먹지 않고 꼼꼼하게 만들어낼 수 있다. 또한 테스트를 작성하는 시간과 애플리케이션 코드를 작성하는 시간의 간격이 짧아진다.

또, 매번 테스트가 성공하는 것을 보면서 작성한 코드에 대한 확신을 가질 수 있다.

TDD에서는 테스트 작성하고 이를 성공시키는 코드를 만드는 작업의 주기를 가능한 짧게 가져가도록 권장한다.

사실 모든 개발자는 TDD를 몰라도 이미 테스트가 개발을 이끌어가는 방식으로 개발을 하고 있다고 생각한다. 한번 생각해보자. 새로운 기능을 가진 코드를 만들려고 하는 순간, 개발자의 머릿속에서는 ‘이런 조건하에 이런 작업을 하면 이런 결과가 나올 것이다’ 라는 식으로 기능을 먼저 정리하게 될 것이다.

코드를 작성하는 동안에도 눈으로 훑어보면서, ‘이런 조건의 값이 들어오면 코드의 흐름과 조건을 따라 이렇게 진행 되서 이런 결과 값이 나오겠다’ 라는 식으로 시뮬레이션을 계속 하게 된다.

문제는 이렇게 머릿속에서 진행되는 테스트는 제약이 심하고, 오류가 많고, 나중에 다시 반복하기가 힘들다는 점이다. 그래서 차라리 머릿속에서 복잡하게 진행하던 작업을 실제 코드로 끄집어 내놓으면 이게 바로 TDD가 된다.

'눈물 젖은 커피와 함께 며칠 간 밤샘을 하며 오류를 잡으려고 애쓰다가 전혀 생각지도 못했던 곳에서 간신히 찾아낸 작은 버그 하나의 추억'

-> 진작에 충분한 테스트를 했었다면 쉽게 찾아냈을 것을