개발을 통한 자기수양 - benelog

  FindBugs를 이용한 코드검사를 Maven2을 통해 실행하고, Hudson을 통해 확인하는 설정을 정리해 봅니다. Hudson을 설치하는데 필요한 정보를 추가로 얻고 싶으신 분들은 http://benelog.springnote.com/pages/1822522 페이지에 모아진 링크를 참조하시면 어렵지 않게 진행하실 수 있으실 것입니다.

   Eclipse에서 findbugs로 코드검사를 해볼 수 있는 툴은 http://findbugs.cs.umd.edu/eclipse/ 를 update site로 지정하면 설치할 수 있습니다. 설치가 잘 되었다면 소스 폴더를 선택하고 마우스 우클릭을 하면 'Find Bugs'라는 메뉴가 생긴 것이 보일 것입니다. 그 메뉴를 통해 원하는 프로젝트를 검사하고, Bug Explorer 탭을 선택하보면 아래와 같은 화면이 나옵니다.

 Bug Explorer 탭에서는 버그를 유형별로 정리해서 보여주고, 소스탭에서는 해당하는 코드에 벌레 모양 아이콘을 찍어줍니다.그리고 Problems 창에서는 Eclipse에서 잡아내는 다른 경고처럼 warning으로 해당 소스를 표시해 줍니다. BugDetails 탭을 누르면 버그에 대한 자세한 설명도 볼 수 있습니다.

  프로젝트의 Properties 메뉴에서 FindBugs 설정란으로 가면 검사할 규칙 등을 선택할 수 있습니다.

 이 설정화면에서 'Run FindBugs automatically'를 선택하면, 소스가 바뀔 때마다 자동으로 검사를 수행해줍니다. 이 기능이 선택되어 있지 않다면, 지적된 소스를 수정해도 다시 수동으로 검사를 돌려야지 경고메시지 지워지므로,이클립스가 아주 느리다는 느낌이 안 들정도라면 선택하는 것이 좋습니다.

  Detector Configuration 탭에서는 검사할 규칙들을 지정할 수 있고, Reporter configuration 탭에서는 보고해 줄 버그의 경고단계와 분류를 선택할 수 있습니다.

Filter files 탭에서는 별도의 XML파일로 선언된 포함하거나 제외시킬 버그와 파일에 대한 설정을 가지고 올 수 있습니다.

 아래에 자세히 설명하겠지만,  Maven 설정에서 참조하는 findBugsExclude.xml을 Eclipse plugin에서도 똑같이 지정해서 Maven과 Eclipse에서 같은 기준으로  검사가 수행되도록 했습니다.

  Maven2의 findbugs-maven-plugin은  pom.xml에 아래와 같이 설정됩니다.

<plugin>
   <groupId>org.codehaus.mojo</groupId>
     <artifactId>findbugs-maven-plugin</artifactId>
     <version>1.2.1</version>
     <configuration>
       <findbugsXmlOutput>true</findbugsXmlOutput>
       <findbugsXmlWithMessages>true</findbugsXmlWithMessages>
       <xmlOutput>true</xmlOutput>
       <excludeFilterFile>${basedir}/findBugsExclude.xml</excludeFilterFile>         
    </configuration>
</plugin>

  위의 설정에 들어가는 속성들에 대해서는 findbugs-maven-plugin 설명 페이지에서 자세한 내용을 보실 수 있습니다.

  저는 제외할 검사규칙을 지정하기 위해서 excludeFilterFile속성에 findBugsExclude.xml을 지정했습니다.

findBugsExclude.xml의 내용은 아래와 같이 설정했습니다.

<FindBugsFilter>
    <Match>
          <Bug code="Se,SnVI,Dm" />
    </Match>
</FindBugsFilter>

  제외할 것을 선언하는 파일에 이렇게 적었으니 Bug code가 "Se,SnVI,Dm"에 해당하는 버그검사는 제외한다는 의미입니다. Filter의 설정 방법에 대해서는 findbugs의 매뉴얼을 참조하시면 됩니다.

  버그 코드 중 Se,SnVI는 serialVersionUID에 관한 것이고 Dm은 String.toUpperCase 등의 메소드에서 Local설정을 권유하는 검사입니다.   (버그 코드에 대한 설명 페이지 참조)

 이렇게 설정을 하고 mvn findbugs:findbugs로 maven을 실행시키면 필요한 라이브러리들을 다운로드 받고 빌드가실행됩니다. 실행이 성공했다면 목적지 폴더에 findbugs.xml과 findbugsXml.xml파일이 생성이 되었을 것입니다.

  이것을 Hudson을 통해서 보기 위해서는 Hudson에서도 findbugs plugin을 설치해야 됩니다.

 Hudson 첫 화면에서 Manage Hudson - Manage Plugins 메뉴를 찾아갑니다. Available 탭에서findbugs를 선택하고 화면 우측하단의 'install'버튼을 누르면 Hudson이 알아서 라이브러리를 다운 받아줍니다.설치한 plug-in이 실행되기 위해서는 Hudson을 재시작해야 합니다.

  그런 다음에 findbugs를 적용하고자 하는 프로젝트에 가서 Configure메뉴를 선택하면 아래와 같이 Publish FindBugs Analysis Result라는 부분이 추가된 것을 보실 수 있을 것입니다.

  이것을 선택하고 원하는 기준값이 있을 경우 입력한 뒤에 "save'버튼을 누르고 build를 해보면 됩니다. 물론 build에는 findbugs:findbugs goal이 포함되어야 하겠죠.

  빌드가 성공하는 것을 보고 프로젝트의 메뉴를 보면 FindBugs Warnings라는 메뉴가 추가된 것을 확인하실 수 있습니다.

  그 메뉴를 누르면 생성된 보고서가 보입니다.

  warning이 존재할 경우 건수를 클릭하면 해당하는 클래스들이 나오고, 클래스를 선택하면 소스에서 warning을 발생시키는 부분까지 보여줍니다.

 만약 hudson의 findbugs plugin을 실행할 때 Cannot find setter nor field inorg.apache.maven.plugins.site.SiteMojo for 'xmlOutput' 와 같은 에러가 난다면 Hudson plugin 수동으로 빌드&업로드를 참조해서 최신 버전으로 플러그인을 업데이트 해보시기 바랍니다.

관련 자료

• Sun Techdays 2008 Lightning Talk 발표자료; findbugs
  
• Hudson의 Findbugs 플러그인 이용하기
• findbugs eclipse plugin 설치
• FindBugs: 코드의 정적 분석을 통한 버그 탐색 : 동영상 강연을 보니 구글에서도 이 도구를 사용하고 있다고 합니다.
  

  EMMA는 테스트코드가 검증해 주는 코드영역에 대해서 보고해 주는 도구입니다. 전체 코드 중 몇 %가 테스트 코드를 거쳐가고 있는지 쉽게 수치를 낼 수 있습니다.

  EMMA의  Eclipse plugin인 EclEmma는 http://update.eclemma.org/를 plugin의 update site로 지정하면 설치할 수 있습니다.  설치 후 프로젝트에서 우클릭-Coverage As - JUnit Test 메뉴를 선택하면 전체 Junit Test를 실행하고, Test Coverage에 대한 보고서를 생성해 줍니다.

  실행결과는 아래와 같이 코드창에서도 테스트 코드가 거쳐가는 곳과 아닌 곳을 색깔별로 표시해 주고, 패키지별, 클래스별로도 coverage 수치를 보여줍니다.

(이미지 출처: http://update.eclemma.org/ 에서)

  EMMA의 Maven2 plugin인 Emma Maven Plugin Maven을  pom.xml파일의 reporting 선언에 아래와 같은 설정을 추가합니다.

<reporting>
  <plugins>
   ...
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>emma-maven-plugin</artifactId>
      </plugin>
    </plugins>
</reporting>

Hudson의 위키에 있는 Emma plugin 설명페이지나 Maven의 emma-plugin 설명페이지를 보면 build절에도 plugin 설정을 추가하라고 되어있는데, 그렇게 하지 않아도 잘  실행이 되었습니다.  오히려 그렇게 추가를 하니, mvn test site처럼 test와 site phrase가 같이 돌아갈 때 아래와 같은 에러가 발생했습니다.

java.lang.IllegalStateException: class [......] appears to be instrumented already

  Emma plugin 설정을 reporting 부분에 넣으면 테스트가 실행되므로 일부러 test phrase를 넣어줄 필요는 없습니다. 즉 이 때는 mvn site만 돌려주시면 테스트 결과와 Coverage Report를 모두 얻을 수 있습니다.  emma plugin이 있을 때 'mvn test site'로 실행시켜서 테스트가 두번 돌면 Hudson에서 보고하는 테스트 개수도 2번씩 중복 집계가 되므로 더 혼동만 줍니다.

  Maven의 emma-plugin 설명페이지에 따르면,  maven-surefire-plugin 설정에서 별도의 JVM으로 테스트를 실행시키위해 forkMode를 always로 설정하는 것은 중요하다고 합니다. EMMA가 JVM의 종료 때도 기록을 하기 때문에 그렇다는군요. 다음과 같이 설정합니다.

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <inherited>true</inherited>
        <configuration>
          <forkMode>always</forkMode>
          <reportFormat>xml</reportFormat>
        </configuration>
</plugin>

  이렇게 Maven을 통해 생성한 리포트를  Huson으로 보기 위해서는 Manage Hudson>Manage Plugins 메뉴에서 Hudson Emma plugin을 설치하고 Hudson을 재시작합니다.

 설치가 잘 되었다면, 프로젝트의 Configure 메뉴에서 EMMA의 보고서에 대해서 설정할 수 있는 항목이 생깁니다.

 여기에서 Emma XML report 항목에 workspace를 기준으로 한 상대적인 경로로 coverage.xml의 위치를 지정해줍니다. Hudson의 위키에 있는 Emma plugin 설명페이지에 보면 이 항목이 target/site/emma/coverage.xml으로 되어 있어서 혼동이 오기 쉬운데, trunk와 같은 Local module directory를 반드시 포함시켜줘야 합니다. 보통 SVN을 쓸 때 프로젝트 설정에서 별도로 지정을 하지 않으면 trunk같은 SVN의 path의 마지막 디렉토리가 Local module directory로 지정됩니다.

  Emma 보고서 설정란에서 the work space root라는 링크를 눌러도 금방 확인 할 수 있습니다.

  위와 같이 설정된 프로젝트를 build하면 빌드의 맨 끝에 Recording Emma reports trunk/target/site/emma/coverage.xml 와 같은 메시지가 Console out 화면에서 뜰 것입니다.  그렇게 생성된 보고서는 프로젝트명>빌드번호>Coverage Report 메뉴에서 보실 수 있습니다.

  만약 Hudson에서 Emma를 실행한 빌드번호의 메뉴에서 'Coverage Report'라는 메뉴가 보이지 않는다면 Hudson plugin 수동으로 빌드&업로드를 참조해서 최신 버전으로 플러그인을 업데이트 해보시기 바랍니다.

   JDepend는 Java패키지간의 의존성에 대한 수치들을 알려 주는 도구입니다.

   JDepend의 Eclipse의 Plugin은 http://andrei.gmxhome.de/eclipse/를 Update site에 추가하면 설치할 수 있습니다. 다음의 링크들에서 보다 자세한 내용을 참조할 수 있습니다. 분석을 하고자 하는 소스폴더 위에서 우클릭을 한 후 'Run JDepend Analysis' 메뉴를 선택하면 의존성 분석 결과가 나옵니다.  

  이를 Maven을 통해서 생성하는 jdepend-maven-plugin 은 pom.xml에 아래와 같이 추가할 수 있습니다.

<reporting>

.....

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>jdepend-maven-plugin</artifactId>
  <version>2.0-beta-2</version>
</plugin>

</reporting>

mvn jdepend:generate 또는 mvn site명령을 통해서 보고서가 생성됩니다. mvn site로 실행했다면 Hudson의 프로젝트 홈에서 Maven Generated Site 메뉴를 통해서도 확인할 수 있습니다. 샘플페이지 에 생성된 보고서의 형식이 나와있습니다. 

JDepend 첫페이지나 생성된 보고서 안에서도 위의 요약 테이블에  수치들에 대한 설명이 잘 나와있습니다. 간단히 요약해서 정리하면,

• TC (Total Classes) : 전체 클래스 수. CC + AC
• CC (Concrete Classes) : Inteface나 추상클래스가 아닌 구상 클래스 수
• AC (Abstract Classes) : Interface나 Abstract Class로 선언된 클래스 수
• Ca (Afferent Couplings) : 이 패키지를 의존하고 있는 다른 패키지의 수. 이 패키지의 책임감을 나타내는 지표
• Ce (Efferent Couplings) : 이 패키지가 의존하고 있는 클래스가 있는 다른 패키지의 수. 이 패키지의 독립성을 나타내는 지표.
• A (Abstractness) : 총 클래스 갯수 중 인터페이스나 추상클래스의 비율. 1이라면 해당 패키지는 추상클래스나 인터페이스 밖에 없는 것.
• I (Instability) :   총 결합도 중 이 패키지의 외부의존성의 비율 (Ce / (Ce + Ca)). 변화에 대한 내성을 나타내는 지표. I=0이라면 완전하게 안정적인 것.
• D (Distance from Main Sequence) :  이상적인 균형의 상태인  A + I = 1 의 함수에서 수직으로 떨어진 거리. (아래 그래프 참조)

이미지 출저 : Managing Your Dependencies with JDepend

가장 중요한 것은 패키지 간의 순환참조를 보여주는 Cycles 부분입니다.

  순환참조 관계의 패키지들은 부분적으로 배포될 수도 없고, 한 패키지를 변경할 때 그 영향력을 파악하기도 힘들게 만듭니다. 순환 참조에 대한 자세한 내용은 아래의 링크를 참조하시기 바랍니다.

• Code Organization & Cyclic Dependency Problem
• Cyclic Dependencies
• Managing Your Dependencies with JDepend
  
• Code Organization Guidelines for Large Code Bases - 유겐 휄러

관련자료

• JDepend에서 지원하는 설계 품질 측정치(design quality metrics)
• [Eclipse Plugin] JDepend를 이용한 의존성 검사 개발관련
  
• Eclipse에서 JDepend 사용하기