 |
|
테스트하기, 모니터하기, 저장하기
CI를 값지게 사용하려면 컴파일을 지속적으로 하는 것 이상을 해야 한다. 훌륭한 CI를 위해서는 테스트로 시작해야 한다. 테스팅 프레임워크와는 상관없이 JUnit이나 TestNG 중 하나를 사용할 수 있다. 중요한 것은 이들 테스트를 자주 해야 한다는 것이다. 즉, 코드가 변할 때마다 테스트를 해야 한다.
JUnit으로 테스트하기
다행히 앤트에 JUnit을 설정하는 것은 매우 쉽다: 앤트에는 JUnit을 테스트할 수 있는 junit 작업이 있다. junit 작업을 구성할 때 JUnit 테스트를 어디서 발견할 수 있는지, 이 테스트 결과들을 어떻게 받을 수 있는지 생각할 필요가 있다.
Listing 4. 앤트를 통해 JUnit 테스트 실행하기
<target name="test" depends="compile-tests" description="runs JUnit tests">
<mkdir dir="${test.report.dir}" />
<junit dir="${basedir}" printSummary="on" fork="true" haltonfailure="true">
<sysproperty key="basedir" value="${basedir}" />
<formatter type="xml" />
<classpath>
<path refid="build.classpath" />
<pathelement path="${test.classes.dir}" />
<pathelement path="${classes.dir}" />
</classpath>
<batchtest todir="${test.report.dir}">
<fileset dir="${test.source.dir}">
<include name="${test.pattern}" />
</fileset>
</batchtest>
</junit>
</target>
|
Listing 4에서 junit 작업은 test.source.dir 디렉터리(Listing 1에서 정의된)에서 발견되는 모든 테스트를 실행한다. 더 중요한 건 XML 리포트는 다른 디렉터리(test.report.dir)에 작성된다는 점이다. CI 서버를 설정하기 시작할 때 테스트 리포트가 어디에 작성되는지 알아야 좋다. 기억해 두자.
소프트웨어 검사
앤트 같은 자동화된 메커니즘을 자유자재로 사용한다면 코드 모니터링을 훌륭히 수행할 수 있다. 소스와 바이너리 파일을 훑는 데는 많은 옵션이 있지만 가장 인기있는 옵션은 PMD와 FindBugs다. PMD는 소스 파일을 훑고 거기서 규칙에 맞춰 코드를 확인한 후 문제가 있으면 보고한다. FindBugs도 비슷한 일을 하지만 바이너리 파일(예를 들어 클래스 파일)을 훑고 버그를 보고한다. 이 두 가지 도구 모두 허드슨과 잘 통합된다.
PMD 실행하기
앤트로 PMD를 실행하는 것은 쉽다. 다운로드하여 안내대로 따르면 된다! JUnit 테스트를 실행하는 것과 같이 XML 리포트는 PDM 작동의 부분으로 생성되도록 지정하는 것을 잊지 말자.
Listign 5. PMD로 코드 오류 찾아내기
<target name="pmd" depends="init">
<taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask"
classpathref="build.classpath" />
<pmd>
<ruleset>rulesets/basic.xml</ruleset>
<ruleset>rulesets/braces.xml</ruleset>
<ruleset>rulesets/javabeans.xml</ruleset>
<ruleset>rulesets/unusedcode.xml</ruleset>
<ruleset>rulesets/strings.xml</ruleset>
<ruleset>rulesets/design.xml</ruleset>
<ruleset>rulesets/coupling.xml</ruleset>
<ruleset>rulesets/codesize.xml</ruleset>
<ruleset>rulesets/imports.xml</ruleset>
<ruleset>rulesets/naming.xml</ruleset>
<formatter type="xml" toFile="${default.target.dir}/pmd_report.xml" />
<fileset dir="${source.dir}">
<include name="**/*.java" />
</fileset>
</pmd>
</target>
|
PMD는 코드 기초에 반해 실행할 수 있는 많은 규칙을 가지고 있다. Listing 5는 많은 옵션을 보여주지만 어떤 것을 실행할지 결정하는 것은 전적으로 자신에게 달렸다.
FindBugs 실행하기
FindBugs는 바이너리 파일을 훑는데 대체로 프로젝트 파일을 포함하고 있는 JAR 파일을 훑는 것보다 쉽다. Listing 6의 findbugs 타겟은 jar 타겟에 의존한다.
Listing 6. FindBugs로 버그를 찾아내기는 쉽다.
<target name="findbugs" depends="jar">
<taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"
classpathref="build.classpath" />
<findbugs classpathref="build.classpath" pluginlist="${lib.dir}/coreplugin-1.0.jar"
output="xml" outputFile="${default.target.dir}/findbugs.xml">
<sourcePath path="${source.dir}" />
<class location="${default.target.dir}/plainead.jar" />
</findbugs>
</target>
|
JUnit과 PMD 작업처럼 이후 분석을 위해 FindBugs가 XML 파일을 만들도록 지정해야 한다.
바이너리 파일을 jar에 아카이브하기
최종적으로 프로젝트가 어떻게 배치되는가에 상관없이 WAR이나 JAR 파일을 만들어야 한다. 이 프로젝트에서는 JAR 파일을 만들 것이다. Listing 7처럼 일련의 클래스 파일에서 JAR 파일을 만드는 것은 앤트에서 컴파일레이션을 하는 것처럼 쉽다.
Listing 7. 하는 것은 앤트로 쉽게 바이너리 자산을 아카이브할 수 있다.
<target name="jar" depends="test">
<jar jarfile="${default.target.dir}/plainead.jar" basedir="${classes.dir}" />
</target>
|
본 절과 이전 절에서 몇 가지 타겟만을 만들었지만 궁극적인 결과는 어떤 코드 기반에나 맞는 반복적이고 신뢰성 있는 빌드 시스템을 만들었다는 것이다. 이 빌드 파일은 컴파일을 수월하게 할 뿐 아니라 테스트도 한다. 또한 코드 품질의 특정한 면을 평가할 수 있는 두 가지 다른 검사 도구를 활용한다. 마지막으로 이 빌드 파일로 코드 기반을 JAR 파일에 패키지할 수 있다. 이 마지막 단계는 프로젝트에 따라 다름을 기억하자. 웹 애플리케이션을 만든다면 Listing 7에서 본 것보다 더 제어된 빌드를 원할 것이다. 예를 들어 애플리케이션의 자산으로 WAR 파일을 만들고자 하고 그 다음에 이를 웹 컨테이너에 배치하고 싶을 것이다.
| 
