Gradle 가이드라인

Gradle은 진화된 빌드툴로 빌드, 테스트, 배포, 개발 등을 자동화 할 수 있다.
Ant의 유연성과 효과적인 빌드툴인 Maven의 편리성을 조합하여 많은 오픈소스 프로젝트의 빌드 시스템으로 빠르게 채택 되고 있다.
Ant의 가장 큰 장점은 개발자가 자유롭게 빌드 단위(target)를 지정하고 빌드 단위간의 의존관계를 자유롭게 설정할 수 있다는 것이다. 하지만 자유도가 높다는 것은 잘 활용할 경우 좋은 도구가 될 수 있지만 그렇지 않을 경우 애물단지로 전락할 가능성이 있다.
Maven의 가장 큰 장점은 Convention Over Configuration 전략에 따라 프로젝트 빌드 과정에 대한 많은 부분이 이미 관례로 저해져 있다는 것이다. 따라서 Maven 기반 프로젝트를 경험한 개발자는 Maven을 기반으로 하고 있는 새로운 프로젝트에서도 쉽게 적용할 수 있다는 것이다. 하지만 관례가 항상 좋은 것은 아니며, 특수한 상황이 발생하는 경우에는 맞지 않는 경우도 종종 발생한다.
Gradle은 Ant의 자유도와 Maven의 관례의 장점을 모두 흡수했다. 그리고 Ant와 Maven 빌드 툴 모두 가지고 있었던 가장 큰 단점인 XML에 대한 이슈도 Groovy 언어를 사용해 해결하고 있다.

특징

Groovy 기반의 DSL(Domain Specific Language) 채용
의존성 기반 프로그래밍을 위한 언어
빌드의 구조화
API 제공
Multi Project 빌드
의존성 관리의 다양한 방법 제공
migration의 편이성
build script는 xml이 아닌 Groovy 로 작성
오픈소스로 제공

Maven과 무엇이 다른가 !?

프로젝트 구성과 빌드는 근본적으로 "구성" 이라는 정적인 요소와 "빌드"라는 동적인 요소의 집합이다. 이를 Maven은 정적인 데이터를 저장하는 XML로 만들어서 동적인 행위에 대한 정의를 어렵게 만들었다.
- Maven의 가장 큰 문제이며 이로인한 복잡한 프로젝트에서 설정이 거의 불가능한 상황이 자주 발생한다.
- Gradle은 DSL로 설정 정보를 구성하고, 그 자체가 groovy 스크립트 언어이므로 동적인 작업은 그냥 groovy 코드로 즉석에서 작성하면 된다.
Maven은 상속 구조를 사용해 멀티 모듈을 구현한다. Gradle은 구성 주입(Configuration Injection)을 사용한다.
- Maven에서 특정 설정을 몇몇 모듈에서만 공통으로 사용하려면 불필요하게 부모 프로젝트를 생성하여 설정하고 그것을 자식들이 상속하게 해야 한다. 게다가 다른 모든게 같더라도 약간이라도 설정이 다른 프로젝트가 하나라도 있다면 그 프로젝트는 상속을 할 수 없고, 거의 모든 설정을 중복해서 해당 프로젝트에 넣어줘야 한다.
- Gradle은 공통 설정을 조건에 따라 특정 프로젝트에만 주입 가능하다. 불필요한 프로젝트는 필요없다.
프로젝트에 상대적인 파일 경로로 작업을 할 때 Gradle은 "rootProject.file()"로 쉽게 구성 가능하다.
Maven은 자신만의 플러그인을 만들기가 힘들다. 하지만 Gradle은 "build.gradle" 혹은 "buildSrc"를 통해 자신만의 플러그인과 태스크를 매우 쉽게 정의할 수 있다.
Gradle은 Ant태스크를 바로 가져다가 사용할 수 있기 때문에 수많은 Java Ant태스크들을 이미 내장하고 있는 것이나 다름없다.
Gradle은 태스크간의 작동 순서 정의가 매우 쉽다. Maven은 정적인 특성 때문에 특정 태스크를 반복 수행하거나 하는 등의 작업이 힘들고, 다른 구문에 태스크를 끼어 넣는 것도 직관적이지 못하다.
Gradle은 Maven플러그인으로 있으나, Gradle 혹은 뭇 플러그인이 없을 경우 그냥 외부 프로그램을 실행해버리거나 groovy로 Maven 플러그인의 java 코드를 호출해서 실행하면 된다.

Gradle 단점

의존성에서 "provided"를 기본으로 제공하지 않고 있다. 하지만 "configurations"를 직접 구성하는 방법이 있다. 의존성 구성(dependency configurations) 참조.
Maven보다 프로젝트 컴파일 / 빌드 속도가 느리다.
이행적 의존성(transitive dependecy) 충돌로 인해 자신도 모르게 지정한 것 보다 높은 버전의 라이브러리를 받아오는 현상이 생긴다. 이것은 문제라기 보다는 Gradle의 의도인데, 이것을 이해하지 못하면 앞서 말한 현상이 생긴다. 의존성 관리 참조.
IDE(Integrated Development Environment)의 지원이 다소 미흡하다.

테스트 환경 및 설치
1. 테스트 환경

Spring Tool Suite(STS) 3.4.0-Release & MacOS OSX 10.9.1
Gradle 1.11
JDK & JRE 6

설치
1. 터미널 설치

http://www.gradle.org/downloads 에서 다운을 받은 후 원하는 폴더에 압축을 푼다.

압축을 푼 폴더의 bin폴더를 환경변수에 설정한다.

터미널에서 "gradle -v" 명령어를 통하여 설치가 되었는지 확인한다.

STS 플러그인 설치

마켓 플레이스에서 gradle 검색 후 아래의 이미지 버전을 설치하면 된다. (이미지는 이미 설치 된 버전을 캡쳐 한 것)

STS 마켓 플레이스에서 gradle검색 시 같이 나오는 "Minimalist Gradle Editor"는 Syntax highlight 기능을 제공한다. (자동완성을 기대했으나 아님)

프로젝트 생성
1. 터미널에서의 프로젝트 생성

프로젝트 생성을 원하는 폴더를 생성한다.
build.gradle 파일을 생성하고 build.gradle 스크립트 작성 같이 스크립트를 작성한다.
gradle의 ⅔ 는 build.gradle 작성에 달려있다. 작성법을 유심히 보고 사용할 것을 권장한다.

STS 프로젝트 생성

STS에서의 Gradle의 적용.
- 기존 프로젝트에서의 build.gradle 파일 생성

build.gradle 파일에 아래와 같은 빌드스크립트(Groovy) 작성
- 빌드스크립트 작성 방식은 build.gradle 스크립트 작성 참고

프로젝트 -> Configure -> Convert to Gradle Project 로 변환

Run As -> Gradle Build -> 실행하고자 하는 Task 선택 후 -> Run (ex로 Build를 실행)

Gradle을 위한 기본 Groovy 언어

Gradle 빌드 스크립트를 제대로 이해하려면 Groovy 언어를 알면 한결 용이하다. Groovy 언어 전체를 학습하려면 비용이 많이 들기에 빌드에 필요한 것 위주로 정리해본다.
변수 선언
- 로컬 변수 : def 변수명 으로 선언. 해당 스크립트 로컬에서만 접근 가능하다.
- ext 변수 : 프로젝트 전체와 서브 프로젝트에서도 접근 가능하다.
- {} 사용

Gradle에서 가장 많이 볼 수 있는 표현법이다.
이 표현법은 ext 변수로 springVersion이라는 이름으로 객체를 할당한다.

Closure

Gradle을 처음 접할 때, Closure잘 모르면 황당하다. 문서 곳곳에서는 compile() 메소드를 사용하지만 어느곳에도 compile() 메소드는 존재하지 않는다.
Gradle의 상당 부분은 closure로 구현되어 있으므로 개념을 확실히 잡아야 한다.
클로저는 함수 객체(function objects) 또는 익명 함수(anonymous function)의 영역안에 묶어 버리는 추상적인 묶음이라고 표현 할 수 있다.
그루비의 클로져는 코드 블록 혹은 메서드 포인터와 같다. 클로져는 정의 후 나중에 실행할 코드 조각을 말한다.
정확한 가이드는 http://groovy.codehaus.org/Closures+-+Formal+Definition 를 참고한다.

List와 Map Literal

Letf Shift Operator(<<)에 대한 이해

doLast method와 같은 목적으로 사용할 수 있다.

"<<"는 doLast와 같은 의미이다. doFirst/doLast는 여러 개 선언될 수 있으며, doFirst가 선언된 순서로 먼저 실행되고, 그 뒤에 doLast가 선언된 순서대로 실행된다.
위의 이미지 실행결과는 다음과 같다.

build.gradle 스크립트 작성
1. plugin 설정

java project를 빌드하는 과정에는 source file compile, 단위 테스트, 그리고 jar파일 생성이라고 한다면 이 일련의 단계들을 gradle의 "java plugin"이 task로 포함하고 있어 모든 과정들이 내부적으로 수행된다.
plugin에 관한 더 많은 정보는 http://www.gradle.org/plugins 에서 확인 할 수 있다.

버전 명시 및 jar manifest 속성 추가

위에서 사용한 플러그인들은 프로젝트에 많은 속성을 추가하는데, 이러한 속성들은 충분히 기본 값을 가지고 있다. 소스에서 사용되는 자바 버전(sourceCompatibitity)에 덧붙여 아래의 이미지와 같이 버전을 명시한다.
또한 JAR manifest에 몇 가지 속성을 추가 할 수 있다. 다음의 사이트에서 manifest 속성을 확인 할 수 있다. http://www.gradle.org/docs/current/javadoc/org/gradle/api/java/archives/Manifest.html

repositories 명시

java 프로젝트는 외부 JAR 파일들에 의존할 경우가 많아, 프로젝트에 jar파일들을 추가하기 위해서는 repository에 존재해야 한다. Maven repository에서 사용하듯이 repository는 프로젝트의 dependencies를 가져올 때 또는 artifacts의 배포에 사용 될 수 있다.
repositories 정의는 default값이 없으므로 꼭 정의가 필요하다. 정의 방법은 아래와 같다.
아래의 이미지처럼 "mavenCentral()"을 사용 하면 기본 Maven repositories를 명시한다.
또는 url을 통하여 maven repository를 remote해서 사용할 수 있다.

ivy repository를 remote하여 사용 할 수도 있으며..

로컬 저장소를 참조하여 사용 할 수도 있다.

maven{}을 여러번 사용하는 것이 가능하며, 사용자 정의 repository에 접속 계정정보를 추가 할 경우이다.

의존성 구성(dependency configurations)
1. Java와 의존성 관리

원칙적으로 자바에는 의존성 관리 기법이 존재하지 않기 때문에 Maven, Ivy와 같은 비표준 솔루션이 만들어지게 되었다.
Maven은 완전한 빌드 시스템이며, Ivy는 의존성 관리만 한다.
Maven과 Ivy 모두 특정 jar에 대한 의존성 정보를 기술하는 XML 파일 기술자(descriptor)를 통해 의존성을 관리한다.
Gradle 의존성 분석 엔진은 pom(Maven)과 ivy 기술자를 모두 지원한다.

의존성 구성

Java에서 의존성은 configurations으로 그룹화 된다. 구성의 각 그룹은 classpath를 의미한다.
많은 Gradle 플러그인들은 의존성 구성을 미리 정의해 두고 있다. 또한 사용자가 스스로 자신만의 구성을 추가할 수 있다. (빌드시에는 필요 없지만 배포는 같이 되어야 하는 추가 JDBC 드라이브 같은 것들이 해당)
프로젝트 구성은 configurations 객체로 관리한다. configurations 객체에 클로저를 전달하면 이 클래스의 API가 호출된다.
Java에서는 기본적으로 네 가지 configuration이 존재한다.

configuration	discription
compile	프로젝트를 컴파일할 때 필요한 의존성 라이브러리들을 추가한다.
runtime	프로젝트를 실행할 때 필요한 의존성 라이브러리들을 추가한다. 기본적으로 컴파일 타임을 모두 포함한다.
testCompile	테스트 소스 프로젝트에서 컴파일 시 필요한 의존성을 추가한다. 기본적으로 컴파일 된 클래스들과 컴파일 의존성을 포함한다.
testRuntime	테스트가 실행 될 때 필요한 의존성을 추가한다. 기본적으로 컴파일, 런타임과 테스트 컴파일의 의존성도 포함한다.

구성하기

configurations의 항목은 http://www.gradle.org/docs/current/dsl/org.gradle.api.artifacts.Configuration.html 에 기술 된 객체이다.

외부 모듈 의존성을 추가하는 방식은 두 가지로 맵 지정방식과 문자열 지정방식이 있다.

http://www.gradle.org/docs/current/javadoc/org/gradle/api/artifacts/ExternalModuleDependency.html 에서 더 많은 property와 method를 볼 수 있다.

의존성이 선언되면 그에 맞는 기술자 파일(pom.xml, ivy.xml)을 찾고, 그에 따라 해당 모듈의 artifact jar파일과 그 의존하는 파일들을 다운로드 한다.

만약 파일이 존재하지 않으면 바로 적합한 파일명을 구성하여 다운로드 한다. (존재하지 않는 버전을 명시 하였을 경우는 deprecated 됨)

Maven에서는 모듈이 하나의 artifact만 존재하지만 Gradle 또는 Ivy는 하나의 모듈이 여러 개의 artifact를 가질 수 있다. 각 artifact는 서로 다른 의존성을 가질 수 있다.

--------------- Maven이 아닌 Ivy, 혹은 Gradle 의 외부 모듈을 가져올 경우 ---------------

만약 다중 artifact 모듈에 의존한다면..

Maven은 다중 artifact 모듈이 있을 수 없으므로 포함 안될 것 이므로, Gradle이 Ivy repository의 모듈에 의존할 경우 발생 한 것이다. Gradle에서 Ivy 모듈에 의존성을 지정할 경우, 정확히는 해당 모듈의 default 구성에 의존성을 지정한 것이므로 실제 의존하게 되는 artifact(보통은 .jar)는 해당 모듈의 default 구성에 첨부된 모든 artifact들이다.
그러므로 default 구성에 원치 않는 artifact가 있을 경우에 해당 모듈을 빼도록 의존성을 구성해야 하며, 필요한 artifact가 default가 아닌 다른 구성에 들어있을 경우라면 어떤 구성의artifact를 가져올지 명시해주어야 한다.

해당 Artifact만 가져오기 지정

특정 모듈을 가져올 때 원칙적으로는 해당 모듈이 의존하는 다른 모듈까지 모두 가져오게 된다.
이 때 해당 모듈의 지정된 artifact(jar)만 가져오고 의존성은 무시하게 만들 수 있다.
문자열 지정법에서는 끝에 @확장자를 지정한다. 보통은 @jar가 된다.(zip파일일 경우는 @zip)
맵 지정법에서는 ext 키에 확장자를 지정한다.
이런일이 가능하게 된 이유는 의존성을 탐색할 때 지정된 확장자의 파일만 다운로드하고 pom.xml이나 ivy.xml같은 모듈 기술자 파일은 다운로드 하지 말라는 뜻이기 때문이다. 모듈 기술자 파일을 받지 않았으므로 의존성을 분석할 수 없기 때문에 해당 모듈의 해당 확장자 파일만 받게 된다. 이미 다운로드 받은 모듈 기술자는 무시한다.

------------------------------------------------------------------------------------------------------

분류자 Classfiler

Maven에는 분류자(classifer)가 존재한다. 분류자는 @ 확장자 지정자와 함께 사용할 수 있다.

다음 task를 만들고 터미널에서 "gradle -q listJars"로 실행한다. 혹은 task없이 "gradle dependencies"만 해도 볼 수 있다.

클라이언트 모듈 의존성

클라이언트 모듈 의존성은 빌드 스크립트에서 직접 이행적 의존성을 선언할 수 있게 해준다. 즉, pom.xml과 같은 모듈 기술자를 대체하는 기법이다.
아래 설정에서는 현재 프로젝트가 groovy에 의존하지만, groovy 자체의 의존성은 무시하고 빌드 파일에서 직접 지정한 의존성을 따르도록 한다.

http://www.gradle.org/docs/current/javadoc/org/gradle/api/artifacts/ClientModule.html 참조

프로젝트 의존성

멀티 프로젝트에서 다른 프로젝트에 대한 의존성을 설정할 수 있다.

이는 "shared"라는 프로젝트에 의존성을 설정 한 것이다.
http://www.gradle.org/docs/current/javadoc/org/gradle/api/artifacts/ProjectDependency.html 참조.

파일 의존성

파일 의존성을 사용하면 jar 파일을 repository에 넣지 고도 의존성에 추가하는 것이 가능하다.
FileCollection(아래의 주소 참조)을 인자값으로 넘기면 된다.

http://www.gradle.org/docs/current/javadoc/org/gradle/api/file/FileCollection.html 참조.

파일이 원래 존재하는 것이 아니라 task를 통해 생성되는 경우, 파일 의존성에 해당하는 파일들을 어느 task에서 생성하는지도 명시할 수 있다.

이와 같이 "builtBy"부분의 "compile"로 지정하여 compile task에 의해 클래스 파일들이 생성된다.

Gradle API 의존성

Gradle task나 plugin을 만들 경우에 현재 Gradle API에 대해 의존성을 지정할 수 있다.
http://www.gradle.org/docs/current/dsl/org.gradle.api.artifacts.dsl.DependencyHandler.html#org.gradle.api.artifacts.dsl.DependencyHandler:gradleApi() 참조.

이행성 의존성 제외하기

이행적 의존성 중에서는 일부는 제외하도록 설정할 수 있다.
- 특정 구성(configuration)에서 이행적 의존성을 제거하면 의존성 구성을 분석하거나 해당 구성을 상속할 때 그 의존성은 제외된다.
- 모든 구성에서 제외시킬 때는 "all*"로 Groovy의 spread-dot 연산자를 사용한다.
- 제외할 의존성 지정시에는 의존성의 이름만 지정(module: '이름')하거나 그룹 이름(group: '그룹이름')만 지정하거나 혹은 둘 다 함께 지정할 수 있다.
- 모든 이행적 의존성이 제외 가능한 것은 아니다. 없어도 되는 의존성인지 주의 깊게 살펴보고 지정해야 한다.
- 의존성 제외가 필요한 경우
  - 의존성 제외가 아닌 다른 방식으로 해결 가능한지 항상 고려한다.
  - 라이센스 때문에 해당 모듈을 빼야한다.
  - 어떠한 원격 리포지토리에서도 받아 올 수 없는 모듈이다.
  - 실행 시점에는 필요 없는 모듈이다.
  - 의존성에 지정된 버전이 다른 버전과 충돌한다. 이때는 버전 충돌 부분으로 해결하도록 한다.
- 대부분의 경우 의존성 제외는 구성 단위로 해야 한다. 그래야 더 명시적이다.
- 의존성 단위 제외의 경우 구성의 다른 의존성에서 제외했던 모듈을 다시 의존할 경우 무용지물이 된다.
- http://www.gradle.org/docs/current/javadoc/org/gradle/api/artifacts/ModuleDependency.html을 참고한다.
- 구성 단위로 제외할 시 아래와 같은 형식으로 정의한다.

의존성 단위로 제외할 시 아래와 같은 형식으로 정의 한다.

혹은 이런 식으로 제외 할 수도 있다.

선택적 속성들

Gradle의 의존성은 여러가지 구성(configurations)을 가질 수 있다.
지정하지 않으면 기본 구성을 사용한다.
Maven에는 기본 구성밖에 없다.
Ivy에는 의존성에 여러 구성을 둘 수 있다.
Gradle의 서브 프로젝트에 대한 의존성을 지정할 때는 다음과 같이한다.

모든 이행적 의존성에서 제외시키기(두 configurations는 같은 코드)

Java 컴파일 시 인코딩 설정

의존성 관리
1. jar 이름에 버전 붙이기

Manifest 파일에 버전을 넣어두기도 하지만 jar파일 자체에 그 일부로 버전 번호를 명시하는 것이 좋다.

이행적 의존성 관리 사용

이행적 의존성 관리를 사용하지 않으면 최상위 의존성을 삭제할 경우 그것이 의존하는 다른 라이브러리가 무엇인지 몰라서 불필요한 jar가 계속 쌓이게 된다.
Gradle은 Maven/Ivy가 아니더라도 일반 jar 파일에 대한 의존성도 지원한다.

버전 충돌

동일한 jar의 서로 다른 버전 충돌은 정확히 찾아내어 해결해야 한다.
이행적 의존성 관리를 하지 않으면 버전 충돌을 알아내기 힘들다.
서로 다른 의존성은 서로 다른 버전의 다른 라이브러리에 의존하기 마련이고, 이 경우 버전 충돌이 일어난다.
Gradle이 제공하는 충돌 방지 전략 :
- 최신 우선 : 가장 최신 의존성이 기본적으로 사용된다.
- 빠른 실패 : 버전 충돌이 일어나면 빠른 시간안에 실패한다. 이렇게 되면 개발자 스스로 충돌을 제어 할 수 있게 된다.

버전 충돌 해결 방법

충돌이 발생하는 라이브러리를 최상위 의존성으로 버전을 명시하여 강제(forced)지정한다.
아무 의존성(이행적이든 아니든)을 강제로 지정한다.

동적 버전(Dynamic Version)결정과 변하는 모듈(Changing Module)

때로는 특정 의존 라이브러리에 대해 항상 최신 버전을 사용하거나, 혹은 특정 version(2.x)최신을 사용하고 싶을 경우가 있다. 동적 버전을 통해 사용 가능하다.
특정 version대를 사용하고 싶을 경우는 버전 명시하는 곳에 4.+와 같이 쓰도록 한다.
사용 가능한 최신 버전을 쓰고 싶을 경우는 latest.integration을, release된 버전의 최신을 쓸 경우 latest.release를 쓰도록 한다.
동적 버전은 실제 버전이 변경되고, 변하는 모듈의 버전은 그대로이지만 그 내용물(jar)이 계속해서 변경 될 수 있다.
기본적으로 동작 버전과 변하는 모율은 24시간 캐시된다. 설정을 통해 바꿀 수 있다.
특정 라이브러리의 변경을 매번 검사해야 한다면 changing = true 옵션을 추가한다.
-SNAPSHOT 버전은 기본으로 changing=true설정이 된다. 단, Maven Repositorty일 때만 그렇다.(Maven 자체의 기본정책인듯 하다). 그러므로 Ivy Repository는 SNAPSHOT이라도 changing = true 설정이 필요하다.

ResolutionStrategy

http://www.gradle.org/docs/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html 참조.

조사 결과 failOnVersionConflict()를 설정하고 의존성을 관리하는 것이 좋다고 한다. 그 이유는 이행성에 의해 버전이 변하는 것을 방지할 수 있기 때문이다.
failOnVersionConflict() -> 동일 모듈에 대한 버전 충돌시 즉시 오류 발생하고 실패
force 'somthing:1.x.x', 'something:2.x.x' -> 특정 모듈의 버전을 강제 지정(최상위건 이행적 의존서이건 상관없이 지정)
forceModules = ['something:3.x.x'] -> 이미 강제 지정된 모듈 버전을 대체함
cacheDynamicVersionFor 10, 'minutes' -> 동적 버전 탐색을 10분 캐시함.
cacheChangingModulesFor 0, 'seconds' -> 변하는 모듈(changing Module)을 캐시하지 않음.

스크립트 예시

먼저 아래의 이미지와 같이 bulid.gradle스크립트를 작성한다

터미널에서 "gradle check" 명령어를 통해 빌드 스크립트가 정상적으로 작성 된 것 인지를 확인한다. 아래의 이미지와 비슷하게 나온다면 정상적으로 작성 된 것이다.

"gradle initProject" 명령어를 통해 소스 디렉토리를 생성한다.
"gradle eclipse" 명령어를 통해 이클립스에 import 할 수 있도록 빌드한다.
빌드 성공 후, eclipse에서 import하여 사용한다.
이클립스 상에서 빌드를 진행하게 되면 아래의 이미지와 같이 프로젝트의 jar파일이 생성되며, 빌드 옵션에 따라 javadoc이 완성되고, test report가 생성된다.

Gradle Test

테스트 소스셋에서 모든 단위 테스트를 자동으로 감지하여 실행한다.
테스트 수행이 끝나면 보고서를 생성한다.
JUnit, TestNG를 지원한다.
test 관련 참조 문서 http://www.gradle.org/docs/current/dsl/org.gradle.api.tasks.testing.Teㅊst.html

테스트 실행
- 테스트는 독립 JVM에서 격리상태로 실행된다.
- test.debug 프로퍼티를 true로 설정하면 디버그모드로 실행되며 5005 포트로 디버깅 할 수 있다.
- 병렬 테스트
  - 여러 테스트 프로세서를 동시에 실행 할 수 있다.
  - "maxParallelForks" 프로퍼티로 테스트 프로세스 갯수를 설정할 수 있다. 기본값은 1이다.(병렬 테스트 안함)
  - 테스트 프로세스는 org.gradle.test.worker 시스템 프로퍼티를 설정한다.
- "forkEvery" 프로퍼티로 몇 개의 테스트를 수행한 뒤에 프로세스를 재 시작 할지를 정할 수 있다. 단위 테스트가 JVM Heap을 너무 많이 소모할 경우 이 값을 작게 준다. 기본은 재 시작 안 함.
- "ignoreFailures" 프로퍼티는 테스트 실패 시 행위를 정의한다. 기본값은 false이며 테스트가 실패하면 즉시 멈춘다. true일 경우 테스트가 실패해도 멈추지 않고 다음으로 넘어간다.
- "testLogging" 프로퍼티는 테스트의 로깅 레벨을 설정한다. 기본적으로 모든 실패한 테스트에 대한 요약 메시지를 보여준다. TestLoggingContainer 참조.
- 표준 출력/에러를 화면에 표시하려면 "testLogging.showStandardStreams = true" 설정 필요.

JUnit

TestNG
- "@Test" 어노테이션을 가진 메소드가 있는 클래스

테스트의 분리
- "*Test"와 "*IntegrationTest"를 분리해서 실행하고자 하는 경우가 있을 수 있다.
- Gradle goodness - Running Single Test 참조
- "include"와 "exclude"를 사용하고 Test를 상속하는 또 다른 태스크를 만들어 지정한다.

TestLogging
- TestLogginContainer 참고

Gradle Life Cycle

Gradle 빌드 툴은 기본적인 라이프사이클을 제공하지 않는다. 이 점이 메이븐 빌드 툴과의 가장 큰 차이점이다. 메이븐 빌드 툴은 빌드 설정 파일이 상속 개념이다. 따라서 부모(parent) 설정 파일에서 제공하는 기본 라이프사이클을 그대로 상속받는 구조이다. 객체 지향 프로그래밍에서의 상속과 똑같은 개념이다. 상속이 좋은 점도 많지만 부모의 속성과 행위를 규정함으로써 강제하는 부분이 많다. 따라서 객체 지향 프로그래밍에서도 상속보다는 구성(composition)을 사용하는 유연한 설계를 할 수 있다고 안내하고 있다.
Gradle 빌드 툴은 메이븐이 가지는 빌드 스크립트의 상속 문제를 해결하기 위해 구성을 통한 확장을 선택했다. 이 구성을 통한 확장의 핵심에 plugin이 있다. Gradle의 기본 설정에는 빌드 라이프사이클이 존재하지 않는다. 하지만 "apply plugin: 'java'" 와 같이 java plugin을 사용하도록 설정하는 순간 자바 프로젝트에 대한 빌드 라이프사이클이 추가된다.
자바 프로젝트를 빌드하는 기본 과정을 유추해보면 다음과 같다.
- production java 코드(src/main/java 소스 코드)를 컴파일 한다.
- production resources(src/main/resources 자원)을 컴파일 output 디렉토리에 복사한다.
- test java 코드(src/test/java 소스 코드)를 컴파일 한다.
- test resources(src/test/resources 자원)을 test 코드 컴파일 output 디렉토리에 복사한다.
- test 소스 코드를 실행해 테스트를 진행한다.
자바 프로젝트를 컴파일하고 테스트하는 과정을 살펴보면 위와 같다. Gradle 빌드 스크립트에 java plugin을 추가하면 자바 프로젝트를 빌드하기 위한 여러 개의 task가 추가된다. 여러 개의 task는 서로 간의 의존관계를 맺으면서 자바 프로젝트에 대한 빌드 라이프사이클을 추가한다. java plugin task간의 의존관계를 살펴보면 다음과 같다.

저작자표시 비영리 변경금지

'util' 카테고리의 다른 글

IntelliJ IDEA CPU 점유율 낮추기 (1)	2017.02.28

참새느님이 짹짹거리고 있습니다.

Gradle 가이드라인

'util' 카테고리의 다른 글

티스토리툴바

Gradle 가이드라인

'util' 카테고리의 다른 글

'util' Related Articles

티스토리툴바