hudson – FindBugs 연동하기

“내가 작성한 코드는 잘 작성한 것일까?”

내가 작성한 코드가 이상없이 동작하는지 검사하기 위해, JUnit 등을 사용하여 테스트를 수행해 왔다면,
이제 이런 질문을 던져볼 만도 하다.

프로그래머가 작성한 코드는 “논리”의 집합이다.

그렇다면, 테스트케이스는 “그 논리가 적합한가?” 혹은 “그 논리에 헛점이 있는가?”를 검증하기 위한
것이라고 할 수 있을 것이다.

그러면, 그 “논리를 세우는 방법이 잘 되어 있는가?”를 검증하는 방법도 있을 법하다.

그래서, “코드검사”를 수행한다!!

코드 검사는 내가 작성하는 코드가 표준에 맞는지, 어떤 잠재적인 오류 패턴을 내포하고 있는지 등을
검사해 준다.

CheckStyle, PMD, FindBugs 등 여러 가지가 있으나, FindBugs를 hudson에 연동하여 사용해 보자.

FindBugs는 어디에?

FIndBugs는 http://findbugs.sourceforge.net 로부터 정보를 얻을 수 있다.
다운로드는 물론이고, 설명도 잘 되어 있다.

설정과정은?

지금까지 hudson과 연결한 다른 플러그인의 설치 방법과 크게 다르지 않다.

* FindBugs 설치하기/ 환경변수 등록하기
* Ant task에 FindBugs 등록하기
* Hudson내 설정하기

의 절차를 따를 것이다.

FindBugs 설치하기

왼쪽 메뉴에 크게 Downloads 섹션이 있다.
링크를 클릭하고, findbugs-1.3.9.zip을 다운 받았다.
이제 원하는 곳에 설치하자.
설치라고 해봐야, 압축풀고 환경변수에 등록하는 일 밖에 없다.

환경변수에

FINDBUGS_HOME=findbugs 설치디렉토리

로 지정하였다.

Ant Task에 FindBugs 등록하기

FindBugs 홈페이지에 자세한 설명이 되어 있다.
세부 내용은 다음 링크를 참조하자. http://findbugs.sourceforge.net/manual/anttask.html

환경변수 설정은 다음과 같이 한다.

<!-- FindBugs configuration/directories -->
	<property name="findbugs.home"  	value="${env.FINDBUGS_HOME}"/> 
	<path id="findbugs.classpath">
		<pathelement location="${findbugs.home}/lib/findbugs-ant.jar" />
	</path>

findbugs라는 task도 다음과 같이 정의한다.

<!-- target : FindBugs -->
	<taskdef name="findbugs" 
			classname="edu.umd.cs.findbugs.anttask.FindBugsTask" 
			classpathref="findbugs.classpath"/>
	
	<target name="findbugs">
		<mkdir dir="${report.home}/findbugs" />
		<findbugs home="${findbugs.home}"
                output="xml:withMessages"
                outputFile="${report.home}/findbugs/findbugs.xml" 
				excludeFilter="${report.home}/findbugs/findbugs-filter.xml" 
				timeout="1800000" jvmargs="-Xmx512m">
			<sourcePath path="${src.home}" />
			<class location="${build.home}" />
		</findbugs>
	</target>

Hudson내 설정하기

먼저, FindBugs 플러그인을 설치하자.
Hudson의 왼쪽 메뉴에 있는 “Hudson 관리하기”를 클릭하고 나타나는 화면으로부터, Manage Plugins를 클릭한다.
Availabe 탭을 클릭하여, 목록을 보면 다음과 같이 FindBugs plugin 항목이 보인다.

FindBugs를 체크하고, 우측 하단의 Install 버튼을 클릭한다.
해당 플러그인을 설치하면, 다음 화면이 나타난다.

이제, hudson을 재시작 해보자.
그러나, 아직 findbugs가 실행되는 것은 아니다. 앞에서 설정한 ant task가 실행되도록 설정하지 않았기 때문이다.

해당 프로젝트로부터 configure 를 클릭하여, ant task를 추가하자.
Build 부분에 Inovke Ant를 추가하여, Targets로 findbugs를 기록한다.
(앞에서 findbugs task를 이미 build.xml에 추가하였다.)

이대로 마치면, 다음 빌드에 findbugs는 실행되지만 hudson에서 직접 결과를 볼 수는 없을 것이다.
findbugs의 report를 publish 하자.

Post-build Actions에 가보면, 어느새 Publish FindBugs analysis results라는 옵션이 생겨있을 것이다.
이를 체크하고, 자신의프로젝트/report/findbugs/findbugs.xml 과 같은 형태로 적어주고 저장한다.

이제 새로 빌드해 보자.
그러면, 왼쪽 부분에 FindBugs Warnings라는 메뉴가 생길 것이다.

FindBugs가 무엇을 했는지는 클릭해 보면 알 수 있다.

(파일명은 일부러 가렸다.)
문제가 되는 부분의 파일명과 Distribution에 색깔로 위험 정도를 표시해 준다.

세부 항목을 잠시 살펴보면,

해당 부분에서 위와 같은 경고 사항이 발생했고, 해결 방법을 권고해 준다.
참고로 위의 예는, 변수를 선언했으나 사용하지 않았음을 알려주는 경우이다.

FindBugs 등의 코드 검사를 수행시키면, 참 많은 잔소리를 듣게 된다.
그러나, 이는 코드의 품질을 높일 수 있도록 도와주는 즐거운 잔소리가 분명하다.

보다 안전한 코딩을 위해, 기꺼이 잔소리를 들어보자!

hudson – javadoc 생성하기

사실, 개발하면서 주석을 다는 것은 무척이나 흥미로운 귀찮은 일이다.
게다가 포맷을 지키고, 어떤 파라미터가 넘겨지고, 리턴 값은 어떻고,
어떤 상황에서 어떤 exception이 던져진다는 것까지 써야 한다면 더더욱 그렇다.

보통 프로그램부터 작성한 후, 주석을 달라고 한다면,
주석을 다는 것이 아주 하기 싫은 일이 될 가능성이 크다고 생각한다.
주석을 달면서, 코드 리뷰도 하고, 분석도 하고, 수정도 하는 선순환이 되기 보다는
상당히 형식적인 주석 작업이 될 확률이 더 높아진다.

오히려, 보다 양질의 주석을 달기에 좋은 시기는 해당 부분을 프로그램화 할 때라고 생각한다.
모든 프로젝트를 완료한 후, javadoc을 사용하는 대신에
초기부터 javadoc을 사용해 보자.

자신이 작성하는 코드와 비슷한 시기에 산출물을 생성하는 것이다.
생성된 산출물을 확인하여, 편집하는 수고를 나중으로 미루지 말자.

다행히, hudson에서는 기본적으로 javadoc을 publish하는 기능이 내장되어 있다.

Hudson의 설정 변경하기

프로젝트의 configure 메뉴를 선택한다.
Post-build Actions에 보면, 별도의 플러그인을 설치하지 않아도 javadoc에 대한 옵션을 설정할 수 있도록
되어 있다.

Publish Javadoc 옵션을 체크하면, javadoc 문서의 위치를 지정할 수 있다.

프로젝트명/docs/javadoc 과 같이 적어준다.
(본인의 경우, 프로젝트명/docs/javadoc에 javadoc 문서가 생성되도록 설정해 두었다.)

ant task 추가하기
javadoc의 디렉토리를 다음과 같이 선언하고,

<!-- javadoc directory -->

	<property name="javadoc.home" 		value="${basedir}/docs/javadoc" />

javadoc의 task를 다음과 같이 선언한다.

<!-- target : javadoc -->

	<target name="javadoc">

		<javadoc sourcepath="${src.home}" windowtitle="J's project" 

			destdir="${javadoc.home}" encoding="UTF-8" charset="UTF-8" 

			docencoding="UTF-8">

		</javadoc>

	</target>

이제, javadoc의 task까지 준비하였다.
ant task로서의 javadoc을 호출하기만 하면 될 것이다.

ant task 실행 설정하기
이제, configure에 Build에 보면, 지난 번에 설정한 all.emma.report  task가 보일 것이다.
그 밑에 새로운 ant task를 추가하자.

위의 설정으로부터, 새로운 ant task는 javadoc이라고 이름을 붙였다.

(일부러, all.emma.report에서 compile을 하도록 했으므로, 위의 ant task 작성시 depends를 설정하지 않았다.)

설정을 저장하고 나면,  hudson 좌측 메뉴에 javadoc 메뉴가 나타날 것이다.

Build Now 를 클릭하거나, 자동으로 빌드가 된 후에 javadoc 생성 여부를 확인해보자.

이로써, hudson에서 javadoc을 생성하고 publsih해 보았다.
이제, 개발하면서 자신의 프로젝트가 빌드되면서 생성되는 산출물의 결과도 함께 확인하며,
문서 작성도 함께 해보자.

hudson – emma와 연동하기 (2/2)

지난 글에 설정한 바대로 ant task를 정상적으로 진행했다면,
ant task로 emma.report 태스크를 수행했을 때, coverage.html과 coverage.xml이 생성되었을 것이다.

참고로, 생성된 coverage.html을 살펴보자.

해당 패키지의 구성중, 클래스/메소드/블럭/라인 기준으로 어느 정도가 test로 커버 되고 있는지를 보여준다.
패키지 이름을 클릭하면,

패키지에 포함된 클래스들이 나타나고, 이 클래스들이 어느 정도 test로 커버되고 있는지 보여준다.
이 중, 아무 클래스나 또 클릭하게 되면,

클래스내의 메소드들이 test로 어떻게 커버되고 있는지 현황을 자세하게 보여주게 된다.

이 결과물은, 별도의 ant task를 수동으로 실행시켜 얻은 결과물이므로,
이제 hudson의 task에 연동하여, 자동으로 build가 되면 emma test를 수행하자.

그러면, hudson이 매 빌드마다 결과물을 자동으로 생성하여 dashboard로부터 볼 수 있도록 설정할 것이다.

“Hudson 관리 > Manage Plugins”를 클릭한다.
Available 탭을 클릭하여 살펴보면,

과 같이, Emma plugin 설치에 대한 체크박스가 있다.
이를 체크하고, 우측 하단 구석에 숨어있는 “Install” 버튼을 클릭하자.

성공적으로 Emma plugin을 설치했다면,
다음 화면을 보게 될 것이다.

설명 문구에 뜬 내용처럼, hudson을 재시작시켜 emma plugin이 정상 동작하도록 하자.
hudson에 다시 접속해보면, 외형상 변화는 아무 것도 나타나지 않는다.
(이제부터 hudson에 emma 설정을 해야 하니까)

프로젝트명을 클릭하고, Configure를 선택한다.
Post-build Actions 부분에 “Record Emma coverage report”가 생성된 것을 확인할 수 있다.
이 체크박스를 클릭하면, 세부 설정 화면이 생긴다.

예전에 ant task로 테스트 했을 경우 coverage.xml이 생성된 경로를 기억하는가?

XML report 경로를 넣는 곳에,
프로젝트이름/report/emma/coverage.xml 등과 같은 형식으로 기록해 준다.
Health reporting은 그냥 디폴트 값으로 사용하기로 한다. 즉, 비워두면 디폴트값이다.

아직 emma report를 생성하는 ant task가 동작하도록 설정하지 않았기 때문에,
build 되더라도 emma report가 자동으로 생성되지는 않을 것이다.

따라서, Post-build Actions 위쪽에 있는 Build > Invoke Ant 옵션을 고치자.

Targets에

all.emma.report

라고 써주고, build.xml에 all.emma.report를 추가해 보자.

<!-- target : all with emma.report -->
	<target name="all.emma.report" depends="clean,emma.report" 
		description="builds the project, excutes tests, and writes emma report"/>

이제, 해당 프로젝트의 왼쪽 메뉴탭을 보면,

와 같이, Coverage Report가 생성됨을 확인할 수 있다.
이 Coverage Report를 클릭해보자.

coverage trend를 표시하는 그래프가 graphics로 나타나는 것을 확인할 수 있다.
이 화면에서도 패키지명을 클릭해 보자.

임의의 클래스도 클릭해보자.

사실, 내용은 앞서 살펴보았던 html과 다를 것이 없다.
다만, 별도의 ant task를 사용자가 실행하지 않아도, 소스를 수정후에 SVN 서버에 commit 하는 것만으로도 충분하다는 것이다.

지금까지 한 작업은 다음의 과정을 자동화한다.

* 소스를 개발/수정 후 commit하면,
* 자동으로 소스를 컴파일하고,
* 테스트 코드도 컴파일해서 테스트를 시행하고,
* 테스트 결과를 보여준다.
* 또한 이 테스트의 적용 범위(coverage)가 어느 정도인지 검사해준다.

이로써, hudson에 ant task를 활용하여 emma를 연동해 보았다.

hudson – JUnit 테스트 추가하기

소스의 품질을 높이기 위해, Junit을 사용하여 테스트를 자동화 하자.

본 포스트에서는 hudson에 junit 테스트를 태스크로 선언하여 빌드시 테스트를 실시하고, 그 결과를 hudson으로 리포트 하도록 설정하고자 한다.

hudson에 등록한 프로젝트로부터 configure를 설정하면, 하단에

와 같이 Junit 테스트 결과를 리포트하겠다는 항목이 있다.

이 기능을 사용하기 위해, 기존에 선언한 build.xml (ant script)에 Junit 테스트 컴파일/ 수행을 하도록 추가할 것이다.
물론, 본인이 작성한 코드를 기반으로 Junit 코드들이 작성되어 있어야 한다.

JUnit 테스트를 수행하고 리포트를 생성하기 위해, 기존에 작성한 build.xml을 다음과 같이 task를 추가한다.

test-compile task는 다음과 같다.

	
	    
	    
		
			<!---->
			
			
				
			
		
	    

test task는 다음과 같다.

	
		
		
			<!---->
			
				
			
			
			<!--  -->
			

			
				
				
			
		

		
			
				
			
			
		
	

참고) 위의 task를 추가하면서 설정한 환경 변수 등은 posting에서 제외하였음

이와 같이 설정하면, hudson에 연동된 프로젝트 task로 기본 소스 컴파일 및 테스트 코드의 실행/ 리포트를 생성하게 된다.

Hudson/Configure에서 JUnit의 report를 입력하는 곳에 “프로젝트명/report/junit/TEST*.xml “의 형태로 입력하고, 저장한다.

다음 빌드 후에, Test Result라는 항목을 왼쪽 메뉴에서 발견할 수 있다.

Test Result를 클릭하면, 테스트 케이스 및 그 결과를 상세하게 볼 수 있을 것이다.
(아직은 초기 예제로 올렸으므로 거의 모두 실패 -_-)

이로써, Hudson에 JUnit 테스트를 연동하고, test report까지 생성하도록 하였다.

이제, 대쉬보드에는 다음과 같은 테스트 결과가 나타날 것이다.

그런데, 이 트렌드는

• 몇 개의 테스트 케이스를 수행하는가?
• 그 중 몇 개가 성공이고, 몇 개가 실패인가? (그 변화 추이는?)

를 나타낼 뿐이다.

그런데,  테스트를 자동으로 수행하지만 이 테스트들이 얼마나 의미 있는 테스트인지는 단순히 테스트의 개수만으로는 알 수 없을 것이다. 즉, 테스트 케이스의 개수가 아니라, 테스트 케이스가 실제 소스의 어느 정도를 테스트할 수 있는지 coverage를 확인해야 보다 의미있는 테스트가 될 것이다.

다음에는 Emma를 적용하여, 테스트의 coverage를 측정하도록 하는 설정을 할 것이다.

hudson – 빌드 자동화 설정하기

지금까지는 수동으로 Build Now를 클릭하여, build를 하는 것이었다면,

이제 Continuous Integration을 위해, 소스 변경본을 감지하여 자동으로 프로젝트를 build 하도록 설정을 해야한다.

우선, SVN 설정 부분에서 다음과 같이 체크박스를 설정한다.

그리고, 주기적으로 소스에 변화가 있는지 검사하도록 다음과 같이 Trigger 옵션을 설정한다.

SCM을 polling 한다는 뜻은, 소스에 변화가 있는지 보고 변화가 있을 경우 build를 수행한다는 뜻이라고 보면 된다.

위의 그림에서 보는 바와 같이,

•  매 5분마다 검사하기 : */5 * * * *
•  매일 오전 9시에 검사하기 : 00 09 * * *

두 개의 옵션을 부여하였다.

이와 같이 설정하기 전에는,

와 같았으나, polling 옵션을 설정 후 일정 시간이 지나자 자동으로 빌드를 시작하였다.

hudson – build 스크립트 작성하기 (IDE로부터 build 스크립트 분리)

프로젝트를 생성했지만, IDE를 사용해서 빌드를 진행하는 과정은 개인의 PC에서만 수행되는 작업일 뿐이다.

Hudson 등의 CI를 사용하는 것은 별도의 빌드 서버를 설정하고자 함이고,
별도의 빌드 서버는 개인의 개발 환경과는 상관없이 빌드를 수행할 수 있도록 설정되어야 한다.

따라서, maven이나 ant 등을 사용하여 별도로 빌드가 이루어지도록 설정할 필요가 있으며,
본 과정에서는 ant를 사용하여, 간단하게 빌드를 할 수 있도록 한다.

당연히, ant가 미리 설치 되어 있어야 하며, (http://ant.apache.org)
ant의 설치 디렉토리는 ANT_HOME으로 설정되어 있어야 한다.

지난 번에 등록한 프로젝트명을 클릭하면, 좌측 상단에 위와 같은 Hudson의 메뉴를 볼 수 있다.
별도의 빌드 스크립트가 지정이 되어 있지 않다면, Build Now를 해도 에러가 발생할 것이므로,
ant가 설정되어 있다는 가정 하에, build.xml을 대략 다음과 같이 작성한다.

입력후, 새로 작성한 build.xml을 SVN repository에 add & commit하자.
이제 Hudson에서 Build Now를 하면, 해당 프로젝트가 build되는 것을 확인 할 수 있다.