개발을 통한 자기수양 - benelog

  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 수동으로 빌드&업로드를 참조해서 최신 버전으로 플러그인을 업데이트 해보시기 바랍니다.

  Hudson의 plugin들은 Manage Hudson>Manage Plugins의 updates 탭에서 최신버전들을 업그레이드할 수 있습니다. 그래서 수동으로 업데이트를 해줘야할 일은 없습니다.

  저는 Hudson을 사용하면서 두 번 수동업데이트가 필요한 상황을 경험했습니다.

Findbugs plugins의 수동 업데이트

(Findbugs plugin에 대한 자세한 설명은 FindBugs + Eclipse + Maven2 + Hudson 참조)

 findbugs plugins을 쓰다가 버전 3.2를 업데이트하니, 전에는 없었던 에러가 발생했습니다. 다음의 메시지를 받았었습니다.

Cannot find setter nor field in org.apache.maven.plugins.site.SiteMojo for 'xmlOutput'

  검색을 해보니 저보다 하루 먼저 이 에러를 발견한 사람이 신고를 했고, 곧 이 에러가 고쳐진  findbugs plugins 버전 3.3이 나왔습니다. (https://hudson.dev.java.net/issues/show_bug.cgi?id=2880 참조)

  나오자마자 적용하려고 하니, update 탭에서 바로 뜨지가 않더군요. Hudson의 사이트에서 바로 최신버전의 findbugs.hpi파일을 다운 받아서 PC에 저장을 한후, Manage Hudson>Manage Plugins > Advanced 탭에서 업로드 시켰습니다.

  설치된 플러그인은 Hudson을  재시작해야지 적용이 됩니다. installed 탭에서는 현재 의도한 버전의 플러그인이 설치되어 있는지 확인할 수 있습니다.

Emma plugin의 빌드와 수동 업데이트

  (EMMA Plugin에 대한 자세한 설명은 EMMA + Eclipse + Maven2 + Hudson 참조)

  Emma plugin은 현재 2007년 7월 이후의 1.8 버전이후로 정식 배포판은 추가로 나오지 않고 있습니다. ( https://hudson.dev.java.net/servlets/ProjectDocumentList?folderID=6664&expandFolder=6664&folderID=5818 참조) 제가 설정한 환경에서는 emma-plugin 1.8버전으로 아무리 빌드를 해봐도 Hudson에서 볼 수 있는 리포트 메뉴가 나오지 않았습니다. 그래서, 소스를 뒤져서 분석을 해보니, 현재 snapshot 버전의 소스에서는 리포트가 생성되지 않을 이유가 없었습니다. 1.8버전과의 소스 비교를 해 보는 것도 번거롭고 해서 최신 snapshot을 직접 빌드시켜서 적용시켜 보기로 했습니다.

  먼저  https://svn.dev.java.net/svn/hudson/trunk/hudson 의 SVN 주소에서 hudson 전체 소스를 check out 받습니다. 그리고 '프로젝트폴더/plugins/emma' 디렉토리에 가서 mvn package를 실행시킵니다. 제가 이렇게 빌드를 시도했을 때의 시점에는 Dependency 중 artifactId가 hudson-test-harnes 인 버전 1.277을 찾을 수 없다고 에러가 났었습니다. 해당 버전을 찾아서 따로 설치해 줄 수도 있지만, 그냥 하나 더 낮을 버전으로 다시 '프로젝트폴더/plugins/emma' 아래에 있는 pom.xml에 dependency 선언을 해 주었습니다. 가장 가까운 거리에 있는 선언의 버전을 따르게 되어 있으니, 해당 pom.xml에서 직접 지정한 버전을 받게 될 것입니다.

  <dependency>
    <groupId>org.jvnet.hudson.main</groupId>
    <artifactId>hudson-test-harness</artifactId>
    <version>1.276</version>
  </dependency>

  그러고 나서 mvn package가 성공적으로 실행되었다면 target디렉토리에 있는 emma.hpi를 찾아봅니다. 그리고 그 파일을 Hudson에 접속해서 Manage Hudson>Manage Plugins > Advanced 탭을 통해서 업로드하고, Hudson을 재시작시키면 됩니다.

  emma-plugin은 1.9-SNAPSHOT 버전을 바꾸고 나서 다시 빌드를 돌리니 잘 작동하는군요.

   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 사용하기