블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Code Inspection Tools

ALM/Build Automation (빌드 자동화) | 2008. 2. 29. 17:16 | Posted by 조대협

Code inspection tools
정적 분석 툴이라고도 이야기 하는데...
모냐 하면
소스코드나 컴파일된 클래스를 넣으면 코드 상에서 발생할 수 있는 예상 되는 버그를 알려주는 것이다. (정적으로 소스 코드를 분석해서..)

예를 들어
1: Address addr = get Address("bcho");
2: if(addr != null){ addr.sendGift("Money");}
3: addr.verify();

위의 코드는 addr이 NULL일때 3번 라인에서 Null Pointer Exception(NPE)가 발생할 수 있다. 실행하지 않아도 예측할 수 있는 내용이다.

이런 위험성이외에도 MultiThreading 에서 Lock문제나 단순하게 Class 명명 규칙을 벗어난 경우 등등 이런 여러가지 패턴을 벗어나서 버그의 가능성이 있는 것을 찾아내주는 것을 Code Inspection Tool이라고 한다.

물론 개발자가 의도한 부분도 있고 사람이 생각한 알고리즘을 기계적인 검사를 통해서 검색해 낸다는게.. 얼마나 정확성이 있겠냐만은... 생각외로 도움이 될 수 있다.

대표적인 툴로는 PMD와 FindBugs (둘다 공짜!!) 가 있고.. 이 둘 역시 Hudson에 멋지게 플러그인되어 빌드때마다 Inspection을 수행할 수 있다.

Find bugs : http://www.ibm.com/developerworks/java/library/j-findbug1/
PMD : http://www-128.ibm.com/developerworks/kr/library/j-pmd/

시간 되면 개발환경 자동화 프로세스에 충분히 포함해볼만한 내용..

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

개발환경 자동화 환경

ALM | 2008. 2. 28. 11:49 | Posted by 조대협
CI(Hudson)
Test(JUnit,Cactus,DBUnit,Cobertura,Japex)
Source mgmt(SVN)
Issue tracking(Mantis)
현재 여기까지 구현해봤는데..
앞으로 해보고 싶은것

1. Hudson Master/slave mode
2. Team City  - http://www.jetbrains.com/teamcity 이거 박재성 팀장님이 사용하시는것 같은데.. 다음에 기회되면 한번 사용해보고 싶긴하다.
3. Mylyn을 이용한 연동 (이클립스 버전땜에 잘 못하고 있었는데...)

아무래도 TeamCity 가 이클립스와 연동되는 기능이 강력해서 좋기는 할거 같은데... 써볼 기회가 없네 그랴...

'ALM' 카테고리의 다른 글

개발 환경 자동화에 관심이 많은 분들께 알립니다.  (0) 2008.03.13
빌드 자동화 연동에 대한 고민  (0) 2008.02.29
개발환경 자동화 환경  (5) 2008.02.28
프로젝트 자동화 도구..  (3) 2008.01.18
Dependency 분석 도구  (0) 2007.11.05
XPlanner  (0) 2007.10.23
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 치요 2008.02.29 15:07  댓글주소  수정/삭제  댓글쓰기

    웃 Team City도 대박이군요
    데일리 빌드 관리를 어떻게 할까 하는 생각을 했었는데 이걸로 하면
    굉장히 좋겠네요.
    요새 대협님 블로그에서 너무 새로운것을 많이 보여주셔서 많은 참고를
    하고 있네요.. 감사합니다

    mantis는 시스템 구축을 해놓으니 윗분들이 너무 좋아하시네요
    프로젝트팀에서는 요구사항이 mantis로 밀려들고 해서 저는 왠지 더 안좋은거 같군요 ㅋㅋ

  2. 조대협 2008.02.29 16:10  댓글주소  수정/삭제  댓글쓰기

    1. 이슈 트랙킹의 경우
    만티스 설치하는 것도 중요하지만 프로세스를 효율적으로 정착 시키는것이 더 중요합니다. 밀려드는 요청에 대한 검증 절차와 담당을 할 큐 메니져를 세팅하는 것이 매우 중요합니다.
    CLOSE 기준을 잘 설정하는 것도 중요하구요.

    그리고 MyLyn을 한번 도입해보시는 건 어떨까요? 매번 Mantis로깅하지 마시고 이클립스에서 이슈 관리를 통합적으로 진행해보시는것도 좋겠습니다.

    2. CI 툴
    팀씨티가 기능은 세분화 되긴 했는데.. Hudson이 사용이 더 쉽고.. 직관적입니다.
    용도에 맞춰서 솔루션을 선택하는게 좋겠습니다.

    참고하세요.. ^^

  3. 치요 2008.03.03 16:43  댓글주소  수정/삭제  댓글쓰기

    1. 저희 같은경우는 외부컨설턴트를 모셔서 현재 시스템을 구축하고 프로세스도 자문을 받아서 현재 사용하고 있습니다. 뭐 Mantis 관련 프로세스는 만족하며 쓰고 있습니다 (Mantis 페이지가 PHP 라는 것을 제외하고요 -_-;). myLyn 이나 Hudson 같은경우는 컨설턴트를 오래하셨던 분들이라서 그런지 잘 모르셔서 나중에나 저희가 저희 업무 프로세서에 맞춰서 적용을 해야 할 것 같습니다 .

    2. 오늘은 Hudson을 받아서 시험해 보았습니다. 굉장히 직관적인 인터페이스도 그렇고 사용도 쉽더군요 . 그냥 바로 ant에서 쓰던 빌드파일과 연결하니 바로 관리가 되더군요. ^_^ . 그런데 한가지 문제가 되던것이 빌드넘버 관리같은경우는 따로 설정된 workspace 에서 관리 되던데 이것을 svn과 연동해서 관리 할 수 없을 지 .. 빌드넘버관련해서 아주 민감한 사안이어서 svn과 직접적으로 연동이 안되면 사용 할수가 없을것 같더군요 ㅜ_ㅜ

  4. 조대협 2008.03.03 20:38  댓글주소  수정/삭제  댓글쓰기

    어디 계신분이신지 한번 놀러오세요. 이번주만 여의도에서 작업중인데요..
    이번주에 개발환경 자동화에 대한 작업을 하고 있습니다.
    같이 공유해보면 서로 도움이 많이 될것 같아요.

  5. 치요 2008.03.08 01:42  댓글주소  수정/삭제  댓글쓰기

    후아 요즘은 별로 이건에 대해 손대지 못하고 있다가
    짬을내서 Mylyn + Mantis연동을 성공했습니다. mantis는 SVN과 연동되어있으니
    이클립스에서 mantis에 등록된 이슈를 Attach해와서 작업 후 반영하면 자동으로 이슈가 갱신되면서 SVN revision 변경을 눈치챈 Hudson 은 빌드와 테스트를 수행이 완료되면 이슈와 관련된 인물들에게 메일을~
    정말 꿈같은 환경이네요 ^_^ 현재는 혼자쓰고있지만 윗분들께 건의 드려서 같이 쓰면정말 효율적인 환경이 될것 같습니다.
    만약 mylyn의 scheduler가 outlook의 일정과 연동되면 더욱 좋겠군요. 위에서 지시사항으로 항상 쓰고 있는데 두번일하지 않고 확실히 계획적인 일을 진행시킬수 있을 것 같습니다.. (물론 부서장님께서 일정을 공유하고 계시기때문에 사육당하는 느낌이 조금... -_-)

망할 WLW

ALM/Build Automation(이클립스) | 2008. 2. 20. 13:18 | Posted by 조대협
WLW 9.X = eclipse 3.1 기반
WLW 10.3 = eclipse 3.2 기반

Mylyn은 eclipse 3.3 부터 지원.

어쩌라고.. -_-;

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG Mylyn, WLW

댓글을 달아 주세요

버그질라 인스톨

ALM/Task Management | 2008. 2. 20. 10:14 | Posted by 조대협
http://blog.naver.com/news2day?Redirect=Log&logNo=60015259326

인스톨 방법

버그 질라 문제점

1. Custom Field를 추가할 수 는 있지만, Custom Field를 검색 조건에 포함 시킬 수 없다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG BugZilla

댓글을 달아 주세요

확장된 단위 테스트 도구

(Cactus & JUnitEE)

 

자바스터디 조대협 (http://bcho.tistory.com)

 지금까지 기본적인 단위 테스트 도구에 대해서 알아보았다.

좀더 상세화된 단위 테스트의 단계를 나눠 보면 다음과 같이 나눠볼 수 있다. 

l        Type 1.코드 단위 테스트

코드상의 로직에 대해서만 테스트를 수행한다.앞 장에서 살펴본 테스트 방법이 일반적인 코드 단위 테스트 방법이다.

그러나 EJB,Servlet과 같은 J2EE 컴포넌트에 대해서 로직이 Dependency를 가지는 경우에는 EJB,Servlet 객체를 직접 연동하는 경우 container (WAS)에 배포하고, 기타 환경 설정이 필요하기 때문에, 로직 테스트를 위해서는 container 환경을 구성하기 전에 동일한 인터페이스를 가지면서 실제 로직은 없고 간단한 return값만 주는 가상의 객체 (Mock Object)이용해서 테스트 한다. Mock Test의 경우는 Spring IOC (Inversion of control)의 기능을 이용하면 좀더 쉽게 테스트할 수 있다. 

l        Type 2. In-Container 테스트

In container테스트는 , 컴포넌트들의 상호 작용과 컴포넌트와 컨테이너간의 상호작용을 테스트 하는 케이스 인데, POJO기반의 객체의 경우 문제가 없지만 J2EE와 같이 Container 위에서 동작하는 컴포넌트인 경우 Container에 배포하고, Container내에서 테스트 케이스를 수행해야 한다.

예를 들어 Servlet 클래스는 WAS환경 위에서만 작동하기 때문에, 테스트 하기 위해서는 JUnit이용하여 Pure Java환경에서는 테스트할 수 없으며 반드시 WAS 환경위에서 테스트가 필요하다. 이렇게 Container 환경내에서 테스트하는 것을 in-container 테스트라 하며,이를 지워하는 테스트 프레임웍으로는 JUnitEE Apache Cactus 테스트이 있다.  

l        Type 3. Acceptance 테스트

사용자 요구 사항에 대한 기능 테스트 이다. 좀더 쉽게 설명하면 사용자의 Use Case에 대한 시나리오에 따라 테스트를 하는것인데, 예를 들어 사이트에 LogIn해서 Form에 어떤 값을 넣고 submit 버튼을 누르면 화면상에 어떤 데이터가 출력되어야 한다는 등의 기능적 시나리오에 대한 테스트 이다. HTML 기반의 기능 테스트를 지원하는 테스트 프레임웍으로는 HttpUnit과 이를 확장한 JWebUnit등이 있다. 

l        Type 4.성능 단위 테스트

Type 1~3는 기능에 대한 테스트를 수행하였다면, Type 4는 비기능적인 이슈중에서 성능에 대한 테스트 방법으로, 각 단위 컴포넌트의 수행 시간에 대한 테스트를 수행하는 것이다. 성능 단위 테스트를 지원하는 프레임웍으로는 JPerfUnit등이 있다. 

지금까지 확장된 단위 테스트 방법에 대해서 살펴보았다. 지금부터는 이런 확장된 단위테스트를 수행할 수 있는 구체적인 테스트 프레임웍에 대해서 소개하고자 한다. 

(1)  In-container test - Catcus & JUnitEE

Type 2에서 언급한 in-container 테스트를 위한 프레임웍으로는 Apache Catcus JUnitEE이 있다.

두 프레임웍 모두 In-container 테스트를 가능하게 해주지만, JUnitEE의 경우 Catcus에 비해서 상대적으로 사용하기가 쉽다.JUnit TestCase를 구현해주고 JUnitEE의 서블릿을 설치하면, WAS에 리모트로 테스트를 수행할 수 있으며, 웹브라우져로도 테스트가 가능하다.

 Catcus의 경우 사용법은 JUnitEE에 비해서는 비교적 어렵지만, Servlet,JSP,TagLib에 대한 좀더 전문화된 테스트 프레임웍을 제공한다. 

 

EJB의 경우 Remote Interface가 있는 경우에는 In-container가 아니더라도 WAS외부에서 JUnit이용해서 테스트가 가능하지만, Local Interface만 구현한 경우에는 In-container 테스트만 가능하다. Servlet,JSP를 제외한 EJB,JMS,JNDI등의 J2EE컴포넌트들은 In-container test가 아니더라도, JUnit이용하여 리모트로 테스트 하는 것이 가능하다.

그러나 J2EE 솔루션 패키지(EAI,EP,ESB) 의 경우 J2EE의 호출 환경이 container 내에서만 호출되도록 디자인된 경우도 있기 때문에 필수적으로 In-container 테스트를 진행해야 할경우도 있다.

 In-container test의 경우 별도의 테스트 프레임웍 도입에 대한 비용(시간과 교육)이 필요한 만큼 필요성에 대해 고민한 다음 도입 여부를 결정하는 것이 필요하다.

 

 1)    JUnitEE

JUnitEE는 단순하게, TestCase를 컨테이너 안에서 수행할 수 있게 해주는데 그 목적을 둔다. 앞에서 작성한 JUnit 테스트 클래스인 HelloWorldTest EmpDAOTest Tomcat 컨테이너 안에서 수행해보자

 먼저 JUnit,DBUnit,JUnitEE 라이브러리를 다운로드 받은 후 dbunit-2.2.jar,junit.jar junitee.jar webapp WEB-INF/lib 디렉토리에 복사한다.

WEB-INF/web.xml JUnitEETestServlet을 아래와 같이 설정한다.

 

  <servlet>

    <servlet-name>JUnitEETestServlet</servlet-name>

    <description>JUnitEE test framework</description>

    <servlet-class>org.junitee.servlet.JUnitEEServlet</servlet-class>

  </servlet>

 

  <servlet-mapping>

    <servlet-name>JUnitEETestServlet</servlet-name>

    <url-pattern>/TestServlet/*</url-pattern>

  </servlet-mapping>

< 예제. JUnitEE 테스트 서블릿 설치 >

WEB-INF/testCase.txt라는 파일을 아래와 같이 작성한다. 이 파일에는 TestCase 클래명을 정의한다. 이 클래스명으로 JUnitEE가 단위테스트를 실행할 수 있게 된다.

# test Case Def

bcho.test.HelloWorldTest

bcho.simpledb.test.EmpDAOTest

<예제. JUnitEE에서 테스트 클래스를 지정하는 방법 >

위의 방법은 testCase.txt이용하여 TestCase를 지정하는 방법인데, 그 외에도 JUnitEEWar Ant task이용하여 자동으로 testCase.txt를 생성해낼 수 도 있으며 또는 web.xml servlet init parameter testCase가 들어있는 jar파일을 지정하는 방법등을 이용하여 테스트 케이스 클래스를 지정할 수 있다.

다음으로 Tomcat을 기동한후 http://ip:port/webapp_contextname/TestServlet을 수행한다.

사용자 삽입 이미지

<그림. JUnitEE의 테스트 선택화면 >

웹 화면상에서 등록한 테스트 케이스를 확인할 수 있으며 선택해서 테스트를 진행하게 되면, 다음과 같이 결과를 웹상으로 확인할 수 있다.

사용자 삽입 이미지
< 그림 JUnitEE의 테스트 결과 >

간단하게 JUnitEE이용해서 In-container 테스트를 수행하는 방법에 대해서 알아보았다.EJB JMS같은 J2EE컴포넌트들 역시 같은 방법으로 테스트가 가능하다.

또한 예제의 테스트 방법은 웹브라우져를 통해서 테스트를 수행하는 방법이었는데, 이 외에도 ant task이용해서 ant이용하여 테스트 자동화에 포함하는것도 가능하다. 

2)     Cactus

( http://jakarta.apache.org/cactus/)

또다른 in-container 단위 테스트 프레임웍인 Cactus  에 대해서 알아보자, Cactus Apache 자카르타 프로젝트의 일부로,JUnitEE JUnit 클래스를 서버에서 단순호출 해주는데 비해서 Cactus J2EE컴포넌트에 대한 좀더 정교한 테스트를 지원한다.

Cactus에서 지원하는 J2EE 컴포넌트로는 Servlet/JSP, Filter, TagLib,EJB 테스트들이 있으며, 이러한 테스트를 위한 클래스들을 지원한다.

 예를 들어 Servlet을 테스트하고자 할 때 JUnitEE를 사용하면 단순한 Java 객체로밖에 Servlet을 테스트할 수 밖에 없다. 그러나Servlet을 제대로 테스트하기 위해서는 HttpRequest 내용을 채워넣고, Servlet을 수행한후 Cookie Session 값들을 체크하고, HttpResponse의 내용을 체크해야 한다. 이런 일련의 작업들을 개발자가 일일이 Pure Java Code이용해서 테스트 코드를 만들어내기란 여간 까다로운 작업이 아니다.

 Cactus에서는 이러한 HttpRequest,Cookie,HttpReponse,Session,ServletConfig Servlet을 테스트하기 위해서 필요한 클래스들을 내장 클래스 형식으로 지원하여 쉽게 Servlet을 테스트할 수 있도록 해준다.

 JSP ServletFilter들도 마찬가지 원리로 지원해주게 된다. 

이해를 돕기 위해서 간단한 서블릿을 테스트하는 환경을 만들어보자.

서블릿은 Http Request를 통해서 id passwd를 입력받고, 이 값을 비교해서 맞으면 session id값을 저장하고 Login이 성공하였음을 response로 보내는 간단한 서블릿이다.

public class LogInServlet extends HttpServlet {

 

  public void doGet(HttpServletRequest req, HttpServletResponse res)

      throws ServletException, IOException {

 

    PrintWriter out = res.getWriter();

    HttpSession session = req.getSession();

 

    String id = req.getParameter("id");

    String passwd = req.getParameter("passwd");

 

    if(checkLogin(id,passwd)){

        // 로그인이 성공하였으면 세션에 ID 저장한다.

        session.setAttribute("id", id);

          out.print(id+" Login failed");

    }

   

    out.print(id+" Login success");

}// doGet

:

 

< 테스트할 서블릿 > 

이 서블릿을 테스트하기 위해서 Cactus로 테스트 케이스를 만든후, id passwd HttpRequest로 보낸후, session id가 저장되는지 확인한후, HttpResponse“success” 라는 문자열을 리턴하는지 확인하면,  서블릿이 정상적으로 동작하는 것을 확인할 수 있다.

Cactus로 만드는 테스트 클래스는 org.apache.cactus.ServletTestCase를 상속 받아서 구현되어야 하며, beginXXX testXXX,endXXX 메서드를 구현해야 한다.

beginXXX메서드는 test를 수행하기 전에 WebRequest 객체를 받아서 HttpRequest를 만드는 역할을 하고, testXXX에서는 실제로 테스트를 수행하며, endXXX에서는 Servlet의 수행이 끝난후에 WebResponse 객체를 받아서 HttpResponse 내용으로 테스트 결과를 검증하는 과정을 거친다. 

아래 샘플코드를 살펴보자

package bcho.servlet.test.catcus;

 import org.apache.cactus.Cookie;

import org.apache.cactus.ServletTestCase;

import org.apache.cactus.WebRequest;

import org.apache.cactus.WebResponse;

 import bcho.servlet.LogInServlet;

 public class TestLogInServlet extends ServletTestCase{

       public void beginLogin(WebRequest theRequest)

       {

             theRequest.addParameter("id", "bcho");

             theRequest.addParameter("passwd","passwd");

       }

       public void testLogin()

       {

           LogInServlet servlet = new LogInServlet();

             try{

                 servlet.init(config);

                

                 // Call method to test

                 servlet.doGet(request, response);

           }catch(Exception e){

               e.printStackTrace();

               assertTrue(false); // Exception 발생하였을 경우 실패로 간주한다.

               return;

           }

           // Perform some server side asserts

      

           assertEquals("bcho", session.getAttribute("id"));

       }

 

       public void endLogin(WebResponse theResponse)

       {

           // Asserts the returned HTTP response

             // 리턴되는 HTML 로그인 성공 메세지가 있는지 확인한다.

             String responseTxt = theResponse.getText();

             assertTrue(responseTxt.indexOf("success") > 0);

            

       }

 

}

< Cactus 서블릿 테스트 케이스 >

 beginLogin에서 request객체에 addParameter id passwd를 저장한다.testLogin에서 servlet.doGet을 수행하고, session“id”“bcho”라는 문자열이 저장되었는지 확인한다.endLogin에서는 servlet에서 나온 HttpResponse“success”라는 문자열이 있는지를 확인한다.

서블릿과 서블릿 테스트 클래스가 완성되었으면 이 환경을 서버에 배포해서 테스트를 수행해보자.

먼저 WEB-INF/lib 디렉토리에 http://jakarta.apache.org/cactus 에서 다운 받은 cactus 관련 라이브러리를 복사한다.

( cactus.jar , common-httpclient.jar,common-logging.jar, junit.jar , aspectjrt.jar ) 다음으로 위에서 만든 서블릿 클래스들을 WEB-INF/classes의 패키지 디렉토리에 알맞게 복사한다. 

다음으로 cactus 서블릿들인 ServletRedirector ServletTestRunner 클래스를 WEB-INF/web.xml에 다음과 같이 설정한다.

<?xml version="1.0" encoding="UTF-8"?>

<web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

  <display-name> Einstein Unit Tester Web Application </display-name>

       <servlet>

         <servlet-name>ServletRedirector</servlet-name>

         <servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class>

         <init-param>

           <param-name>param1</param-name>

           <param-value>value1 used for testing</param-value>

         </init-param>

       </servlet>

     

       <servlet>

         <servlet-name>ServletTestRunner</servlet-name>

         <servlet-class>org.apache.cactus.server.runner.ServletTestRunner</servlet-class>

       </servlet>

      

       <servlet-mapping>

           <servlet-name>ServletRedirector</servlet-name>

           <url-pattern>/ServletRedirector</url-pattern>

       </servlet-mapping>

      

       <servlet-mapping>

           <servlet-name>ServletTestRunner</servlet-name>

           <url-pattern>/ServletTestRunner</url-pattern>

       </servlet-mapping>

 

      

</web-app>

 

 서버를 기동하고, 웹브라우져에서 다음과 같은 URL로 접근하면 테스트 결과를 얻을 수 있다.

http://{ip}:{port}/{context-root}/ServletTestRunner?suite={서블릿테스트클래스명}

 필자는 localhost 8080포트에서 context-root Catcus로 배포하였고, 테스트 서블릿은 위에서 작성한데로, bcho.servlet.test.catcus.TestLogInServlet으로 구성하였기 때문에, 테스트 URL은 아래와 같이 구성 된다.

 http://localhost:8080/Catcus/ServletTestRunner?suite=bcho.servlet.test.catcus.TestLogInServlet

 브라우져에서 테스트해서 테스트가 성공하면 다음과 같은 결과를 얻을 수 있다. 

사용자 삽입 이미지

XML 형식이 아니라 좀더 정재되고 보기 편한 형태로 테스트 리포트를 보고 싶을 경우에는 Apache Jakarta 프로젝트에서 제공하는 XSL을 적용하면 되는데, XSLhttp://jakarta.apache.org/cactus/misc/cactus-report.xsl 에서 다운 받을 수 있다.

다운 받은 cactus-report.xsl WebApplication context-root 디렉토리에 저장한후에 QueryString으로 xsl=cactus-report.xsl xsl 파일을 다음과 같이 지정할 수 있다. http://localhost:8080/Catcus/ServletTestRunner?suite=bcho.servlet.test.catcus.TestLogInServlet&xsl=cactus-report.xsl

 XSL을 저장하여 리포트를 생성한 결과는 다음과 같다. 

사용자 삽입 이미지

지금까지 Catcus이용해서In-container 테스트를 하는 방법을 살펴보았다.

테스트를 브라우져에서 진행하였는데, 단위테스트는 위에서도 설명하였듯이 빌드 작업의 일부로 진행이 되고, 빌드는 통상적으로 자동화가 되기 때문에 Catcus이용한 단위테스트 역시 빌드과정에 자동화되어 포함되어야할 필요가 있다.

지금부터는 대표적인 자바 빌드 도구인 ANT를 통해서 Catcus 테스트를 자동화하는 방법에 대해서 알아보도록 하자.

 먼저 디렉토리 구조를 살펴보자, 필자의 경우 다음과 같은 디렉토리 구조를 구성하였다.

사용자 삽입 이미지
*.java 파일은 src 디렉토리에 위치하였으며, 개발에 필요한 각종 jar 파일은 lib 디렉토리에 저장하였다. web.xml과 같은 config 파일은 conf 파일에 저장하였다.

 ANT로 빌드를 진행하면, *.class 파일은 ./build 디렉토리에 저장되고, ./build디렉토리에 저장된 클래스와 ./lib 디렉토리의 라이브러리 그리고 ./conf/web.xml 파일은 pack 디렉토리에서 Cactus.war라는 파일로 패키징되서 저장된다.

 다음은 작성한 ANT 스크립트이다. BUILD에서부터 WAR 파일 생성까지를 진행하고, “cactus-test” 라는 task에서 cactus 테스트를 수행하도록 설정하였다. (진하게 블록으로 표시한 부분) 빌드와 패키징 부분에 대한 설명은 생략하고 cactus 이용 ANT TASK 부분을 살펴보자. 

<project name="CactusTest" default="cactus-test" >

         <!--

       ============================================================================================

        기본 환경 정보 설정

        =============================================================================================

        -->    

        <!-- 기본 디렉토리 정보 -->

        <property name="project.name" value="Cactus"/>

        <property name="lib" value="./lib"/>

        <property name="src" value="./src"/>

        <property name="build" value="./build"/>

        <property name="packaging" value="./pack"/>

        <property name="conf" value="./conf"/>

 

        <property name="cactus.home" value="D:\dev\lib\jakarta-cactus-13-1.7.2"/>

        <property name="cactus.testlog" value="c:\temp\test-report"/>

        <property name="tomcat.home" value="D:\dev\apache-tomcat-5.5.23\"/>

 

        <!-- jar 파일 경로 -->

        <property name="cactus.jar" value="${cactus.home}/lib/cactus-1.7.2.jar"/>

        <property name="cactus-ant.jar" value="${cactus.home}/lib/cactus-ant-1.7.2.jar"/>

        <property name="commons-httpclient.jar" value="${cactus.home}/lib/commons-httpclient-2.0.2.jar"/>

        <property name="commons-logging.jar" value="${cactus.home}/lib/commons-logging-1.0.4.jar"/>

        <property name="aspectjrt.jar" value="${cactus.home}/lib/aspectjrt-1.2.1.jar"/>

        <property name="cargo.jar" value="${cactus.home}/lib/cargo-0.5.jar"/>

        <property name="servletapi.jar" value="${lib}/servletapi-2.3.jar"/>

        <property name="junit.jar" value="${lib}/junit-3.8.1.jar"/>

 

        <!-- class path 설정 -->

        <path id="cactus.classpath">

            <pathelement location="${cactus.jar}"/>

            <pathelement location="${cactus-ant.jar}"/>

            <pathelement location="${commons-httpclient.jar}"/>

               <pathelement location="${commons-logging.jar}"/>

               <pathelement location="${aspectjrt.jar}"/>

               <pathelement location="${cargo.jar}"/>

               <pathelement location="${junit.jar}"/>

        </path>

        <!--

        =============================================================================================

        Task 정의

        =============================================================================================

        -->    

        <!-- Cactus task 정의 -->

        <taskdef resource="cactus.tasks" classpathref="cactus.classpath"/>

       

        <!-- Clean -->

        <target name="clean">

               <delete dir="${build}"/>

               <mkdir dir="${build}" />

               <mkdir dir="${packaging}" />

        </target>

        <!--

        =============================================================================================

        컴파일

        =============================================================================================

        -->    

        <!-- 소스 컴파일 -->

        <target name="compile"  >

               <javac srcdir="${src}" destdir="${build}">

                       <classpath>

                              <path refid="cactus.classpath"/>

                              <pathelement location="${servletapi.jar}"/>

                       </classpath>

               </javac>

        </target>

        <!--

        =============================================================================================

        패키징

        ${build} 생성된 클래스들과, ${conf} 있는 web.xml 설정 정보를 모아서 하나의 WAR파일로 패키징 한다.

        =============================================================================================

        -->    

        <!-- WAR 패키징 -->

        <target name="packaging" depends="compile" >

               <war warfile="${packaging}/${project.name}.war"      webxml="${conf}/web.xml" >

                       <classes dir="${build}" />

                       <lib dir="${lib}"/>

               </war>

        </target>

       

        <!--

        =============================================================================================

        배포

        LOCAL Machine으로 배포하는 스크립트로 tomcat /webapps 디렉토리에 war파일을 복사한다.

        =============================================================================================

        -->    

        <!-- 배포 -->

        <target name="deploy" depends="packaging" >

               <copy file="${packaging}/${project.name}.war" todir="${tomcat.home}/webapps"/>

        </target>

       

        <!--

        =============================================================================================

        테스트

        =============================================================================================

        -->           

        <!-- Cactus 테스트 -->

        <target name="cactus-test">

                <!-- Run the tests -->

                 <cactus  warfile="${packaging}/${project.name}.war" fork="yes"

                       printsummary="yes"

                     failureproperty="tests.failed"> 

                       <classpath>

                              <path refid="cactus.classpath"/>

                              <pathelement location="${servletapi.jar}"/>

                              <pathelement location="${build}"/>

                       </classpath>

                   <containerset>

                       <!--

                       <tomcat5x dir="D:\dev\apache-tomcat-5.5.23" port="8080"      />

                               -->

                       <generic name="local tomcat" port="8080">

                            <startup target="dummy"/>

                            <shutdown target="dummy"/>

                       </generic>

                      

                   </containerset>

 

                   <formatter type="brief" usefile="false"/>

                   <formatter type="xml"/>

                   <batchtest todir="${cactus.testlog}">

                     <fileset dir="./src">

                       <include name="**/Test*.java"/>

                     </fileset>

                   </batchtest>

                 </cactus>

                 <!-- JUnit(cactus) 테스트 리포트 생성 -->

                 <junitreport todir="${cactus.testlog}">

                       <fileset dir="${cactus.testlog}" includes="TEST*.xml"/>

                       <report todir="${cactus.testlog}" format="frames"/>

                 </junitreport>

                      

                 <fail if="tests.failed"> cactus Test failed</fail>

        </target>

        <target name="dummy">

        </target>

       

       

</project>

                      

<Cactus 실행용 ANT 스크립트 >

 l        cactus 용 테스크 정의하기

먼저 ant cactus 테스크를 추가하자.

CLASSPATH cactus에 필요한 클래스들을 추가한후 taskdef이용하여 cactus.tasks resource로 정의하면 cactus 관련된 task들을 정의할 수 있다. (cactus.tasks는 실제로 cactus에 관련된 jar파일 내에 존재한다.)

        <!-- class path 설정 -->

        <path id="cactus.classpath">

            <pathelement location="${cactus.jar}"/>

            <pathelement location="${cactus-ant.jar}"/>

            <pathelement location="${commons-httpclient.jar}"/>

               <pathelement location="${commons-logging.jar}"/>

               <pathelement location="${aspectjrt.jar}"/>

               <pathelement location="${cargo.jar}"/>

               <pathelement location="${junit.jar}"/>

        </path>

      

        <taskdef resource="cactus.tasks" classpathref="cactus.classpath"/>

    

이제는 cactus 관련 테스크들을 사용할 수 있다.

 l        cactus 테스크 사용

실제로 cactus 테스크를 사용해야 하는데, 테스크의 내용을 나눠보면 크게, 테스트할 WAR파일 설정, CLASSPATH 설정,테스트용 서버 정보 설정, 테스트할 유닛들 지정 및 로그 정리 절차로 나눠볼 수 있다.

 

<cactus  warfile="${packaging}/${project.name}.war" fork="yes"

printsummary="yes" failureproperty="tests.failed">

 

warfile 속성에 테스트할 (서버에 배포한) war 파일을 지정하고, failureproperty에 실패값을 지정한다. 그리고 해당 target 마지막 부분에 이 failureproperty 값으로 아래와 같이 실패 처리를 한다..

<fail if="tests.failed"> cactus Test failed</fail>

만약 이 처리를 하지 않으면 cactus 단위 테스트가 실제로 실패하더라도 ant target에 대한 결과는 Successful로 처리된다.

 다음으로 cactus 테스트에서 사용할 클래스 패스를 지정하는데, cactus 관련 클래스들 이외에, 테스트에 사용된 클래스들을 사용하기 위한 lib들이 포함되어야 하며, 반드시 빌드된 테스트 클래스들을 CLASSPATH에 포함 시켜야 한다. (아래 굵게 표시한 부분)

 

<classpath>

<path refid="cactus.classpath"/>

<pathelement location="${servletapi.jar}"/>

<pathelement location="${build}"/>

</classpath>

 

cactus in-container 테스트이기 때문에 테스트할 컨테이너를 꼭 지정해야 하는데,catcus에서는 테스트할 서버를 직접 기동해서 WAR파일을 배포하는 것 까지 자동화 할 수 있다.Tomcat Orion,Resin,WebLogic까지 지원하는데 자세한 내용은 cactus의 문서를 참고하도록 하고 필자는 generic이란 element이용하여, 단순하게, 테스트할 서버의 URL PORT만 지정하였다. (테스트할 서버는 서블릿과 테스트 서블릿이 배포된 서버를 의미한다.)

<containerset>

<generic name="local tomcat" port="8080">

      <startup target="dummy"/>

      <shutdown target="dummy"/>

</generic>

</containerset>

:

<target name="dummy">

</target>

 

그리고 두개의 element 를 지정해야 하는데, startupshutdown 엘리먼트이다.

이 엘리먼트는 서버가 기동되어 있지 않은 경우 실행되어 서버를 기동시키고 테스트가 끝난후에 서버를 자동으로 내리는 역할을 하는 “target”을 지정해야 한다. (필수 element 이다.)

필자는 서버의 기동과 정지를 ANT 내에서 처리 하지 않고 직접 처리하였기 때문에, “dummy”라는 아무 작업도 하지 않는 target을 정의하여 지정하였다.

다음으로 Unit 테스트에 대한 로그를 저장하는 설정을 진행한다. <formatter> 라는 element를 사용하는데 Cactus JUnit의 확장이기 때문에 JUnit formatter element를 지원한다.

여기서 사용한 formatter type 속성은 두가지로 brief xml 을 사용하였다.

Brief는 테스트의 실패이유를 대략적으로 출력해주는 속성이고 xml은 테스테에 대한 각종 정보(통계,프로퍼티등등)을 상세하게 저장해주는 속성이다.

brief 값은 usefile=”false” 로 설정하여, stdout(화면)으로 출력하도록 하였고, xml usefile을 설정하지 않아서 파일로 저장되도록 하였다. 파일 경로는 다음 설명할 <batchtest> element에서 지정되는 todir 디렉토리에 저장되게 된다.

 

<formatter type="brief" usefile="false"/>

<formatter type="xml"/>

 

이제 실제로 테스트할 테스트 클래스들을 선택해야 하는데 한꺼번에 지정하기 위해서 fileset element이용하여, Test*.java 로 된 모든 테스트 클래스들을 수행하도록 하였고, 로그 파일은 todir로 정의된 ${cactus.testlog} 디렉토리에 저장되도록 설정하였다.

 

<batchtest todir="${cactus.testlog}">

      <fileset dir="./src">

        <include name="**/Test*.java"/>

      </fileset>

</batchtest>

 

cactus 테스트를 수행하기 위한 준비가 완료되었고 여기까지 설정하면 실제로 테스트를 수행할 수 있다.

 

여기에 하나 덧붙여서 설명하면, 테스트 결과는 formatter에서 type=”xml”로 설정한 부분이 XML파일로 저장된다. 그러나 이 파일을 읽기가 쉽지 않기 때문에, xml 파일을 이용하여 보기 쉬운 HTML로 테스트 결과를 생성해주는데 junitreport element를 사용할 수 있다.

<junitreport todir="${cactus.testlog}">

       <fileset dir="${cactus.testlog}" includes="TEST*.xml"/>

       <report todir="${cactus.testlog}" format="frames"/>

 </junitreport>

아래는 <junitreport> 이용하여 테스트 결과를 HTML로 생성한 결과이다.

사용자 삽입 이미지
<그림 junitreport이용하여 Cactus 테스트 결과를 HTML로 생성한 결과 >

자아, 이제 cactus이용한 테스트와 리포트 생성까지 모두 살펴보았다.

다소 복잡하기는 하지만 JUnitEE보다 훨씬 더 정교한 J2EE 컴포넌트 테스트를 지원하고, ANT 스크립트 역시 개발 빌드 과정에서 필요한 부분에 약간만 더 해진것이기 때문에 정교한J2EE 컴포넌트 테스트를 진행하기 위해서는 Cactus를 사용하는 것을 권장한다.

 

 

 

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

빌드 자동화 업체

ALM/Build Automation (빌드 자동화) | 2008. 2. 12. 14:25 | Posted by 조대협
Clover,JiRA, CI 툴등. 이런거 수입해서 국내에서 팔았으면 좋겠다 생각했는데..
벌써 하는 업체가 있었네.. 반갑기도 하고.. ^^
역시 사람들 빠르다는 생각도 들고...

마침 업체가 최종명 선배가 있는 업체기도 해서 기술에 신뢰도 간다...
기회가 되면 프로젝트 초반에 같이 한번 일해보고 싶은 업체.

Architecture Group http://www.arctgroup.com
555-4847
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


Hudson에서 SMTP 서버의 포트를 지정하는 메뉴가 없는데.
이는 Java property를 지정해서 해결할 수 있다.
==
nohup java -Dmail.smtp.host=192.24.3.72 -Dmail.smtp.port=3360 -jar hudson.war --
argumentsRealm.passwd.admin --argumentsRealm.roles.admin=admin > nohup.out &
==

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

Code Inspection Tools  (0) 2008.02.29
빌드 자동화 업체  (0) 2008.02.12
Hudson에서 SMTP PORT 지정하기 (Assign SMTP server port in Hudson)  (0) 2008.02.11
통합 빌드 환경 설정 완료  (0) 2008.02.05
Code Coverage Tools  (0) 2008.02.01
이제는 Trac  (1) 2008.01.24
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG Hudson, port, SMTP

댓글을 달아 주세요

Test Coverage Rate

ALM/Test Automation | 2008. 2. 11. 10:30 | Posted by 조대협
테스트 Coverage rate에 대해 고민하던중 재미있는 글 하나 발견
사실 Coverage rate를 올리는것도 중요하지만, Coverage rate는 value있는 test 로 cover가 되어야 한다. 코드 Coverage rate를 올리는것 자체는 중요하지 않다.
얼마만큼 꼼꼼한 테스트가 도느냐가 문제이지...

여러 문서들을 찾아보니까는 보통 80%의 Coverage를 이야기 하는데, 이정도의 Coverage라면, 적어도 개발 과정 전에 Test 에 대한 방법이 고려된 상태에서 개발을 해야지 않는다면 개발 중간에 일정에 미칠 IMPACT가 어마어마할것이다.
지금 프로젝트는 60~70% 정도를 고민중인데..
어떻게 될려나?

==
http://www.artima.com/weblogs/viewpost.jsp?thread=204677

Agitating Thoughts & Ideas
How Much Unit Test Coverage Do You Need? - The Testivus Answer
by Alberto Savoia
May 4, 2007
Summary
Answer to the question: "What is Testivus' wisdom concerning the proper percentage of test coverage?"

Advertisement
 

Referring to "The Way of Testivus" entry:

http://www.artima.com/weblogs/viewpost.jsp?thread=203994

Morgan Conrad asked: "What is Testivus' wisdom concerning the proper percentage of test coverage?"

Here you go Morgan.

Testivus On Test Coverage

Early one morning, a programmer asked the great master:

“I am ready to write some unit tests. What code coverage should I aim for?”

The great master replied:

“Don’t worry about coverage, just write some good tests.”

The programmer smiled, bowed, and left.

...

Later that day, a second programmer asked the same question.

The great master pointed at a pot of boiling water and said:

“How many grains of rice should put in that pot?”

The programmer, looking puzzled, replied:

“How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”

“Exactly,” said the great master.

The second programmer smiled, bowed, and left.

...

Toward the end of the day, a third programmer came and asked the same question about code coverage.

“Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.

The third programmer smiled, bowed, and left.

...

After this last reply, a young apprentice approached the great master:

“Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”

The great master stood up from his chair:

“Come get some fresh tea with me and let’s talk about it.”

After they filled their cups with smoking hot green tea, the great master began to answer:

“The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.”

“The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”

“I see,” said the young apprentice, “but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?”

The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.

“The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.”

The young apprentice and the grizzled great master finished drinking their tea in contemplative silence

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

9개의 프로젝트로 구성된 WLI 시스템에 대한 통합 빌드 시스템을 구축하였다.
Hudson + ANT + WebLogic Workshop ANT TASK 를 조합해서 구성하였고
Free STMP 서버로 Alert 기능은 지원할 생각이고..

인자 자동 DEPLOY 자동화까지 진행할 예정
다음주면 이건 될것이고..

==

표준화 팀에서 JUnit + DBUnit + Hudson으로 기능 테스트에 대한 자동화를 진행중이고
다음주 부터는 JUnit + Cactus 기반의 Unit 테스트를 구현할 예정이다.

이 과정에서 개발팀에게 Test Case와 Tuning을 위한 Issue Tracking 시스템을 설치할 예정인데.. 아직도 Trac을 할지.. 몰 쓸지를 결정을 못했네 그랴... 차라리 익숙한 Bugzilla를 사용할까?

그담에는 Coverage를 할지 말지 고민해봐야겠다.

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

빌드 자동화 업체  (0) 2008.02.12
Hudson에서 SMTP PORT 지정하기 (Assign SMTP server port in Hudson)  (0) 2008.02.11
통합 빌드 환경 설정 완료  (0) 2008.02.05
Code Coverage Tools  (0) 2008.02.01
이제는 Trac  (1) 2008.01.24
Hudson  (0) 2008.01.22
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Code Coverage Tools

ALM/Build Automation (빌드 자동화) | 2008. 2. 1. 18:03 | Posted by 조대협

상용 도구

Code Pro Anlytix Pro
: 기능이 풍부한것 같고, 정적 코드 분석을 통해서 Complexity 분석도 되고 기능은 풍부한편으로 보인다.
http://www.instantiations.com/codepro/analytix/server/index.html

Clover
: 다들 잘 아는 툴 이미들 많이 사용하고 있고, 널리 알려진 만큼 다른 시스템 (CI툴이나 Issue Tracking Tool, 소스 관리툴)들과의 통합도 쉽다.

오픈소스

Cobertura - 요즘 가장 유행하는 툴이 아닐까도 싶고.. 사용이 쉽고 직관적이다. 추천할만한 툴
EMMA-꽤 오래된듯한 툴 같은데... 여기저기 사례도 충분한거 같고 이클립스 플러그인도 지원한다. 마음에 드는것중 하나가 컴파일이 이미 다된 jar 파일을 emma 위에서 실행 시키면 바로 Coverage 분석도 가능하다는 말씀.. 리포트가 직관적이지 않긴 하지만 이클립스 지원하니까는 커버되지 않을까?
http://emma.sourceforge.net/intro.html

NUinit - 나온지 얼마 안된거 같기도 하고... 오픈 소스 툴 중에서는 가장 허접한듯..

Cobertura는 실컷 써봤고... EMMA를 한번 써볼까나?

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

Hudson에서 SMTP PORT 지정하기 (Assign SMTP server port in Hudson)  (0) 2008.02.11
통합 빌드 환경 설정 완료  (0) 2008.02.05
Code Coverage Tools  (0) 2008.02.01
이제는 Trac  (1) 2008.01.24
Hudson  (0) 2008.01.22
Atlassian Bamboo  (0) 2007.11.08
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

WLW에서 WLI나 WLP 애플리케이션들을 ANT 스크립트로 빌드할 필요가 있다.
절차는 다음과 같다.
===

1. 각 프로젝트별로 File>Export > Workshop ANT Script로 build.xml 을 생성한다.
2. EAR 프로젝트에서 File>Export >Workshop ANT Metadata를 생성한다.
이때 같이 빌드될 모든 프로젝트를 선택한다.
NEXT를 누르면 각종 절대 경로들을 설정하게 나온다. 이 경로를 설정해야 한다.
3. Remote server에 Project 디렉토리들을 업로드한다. workspace.xml 로 업로드 한다.
4.
EAR 프로젝트에서
ant -Dworkspace={workspace.xml 경로} -Dwl.home=웹로직 홈 경로 build
ant -Dworkspace={workspace.xml 경로} -Dwl.home=웹로직 홈 경로 archive를 하면 된다.

참고 : 이클립스 프로젝트 내의 .metadata 디렉토리는 이클립스 환경에서의 디렉토리를 관리하기 때문에 이 디렉토리는 REMOTE로 복사하면 안되고 환경 정보는 workspace.xml 에 정의해야 한다.

참고 자료 : http://forums.bea.com/thread.jspa?threadID=300002040

==
이것때문에 몇일을 까먹었냐.. -_-


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

휴우....
다들 알다 싶이, 이클립스에서 개발을 할때는 동시에 여러개의 프로젝트를 열어서 개발을 하게 되고, 프로젝트간의 Dependency를 지정하는게 중요한데.
이게 개념을 모르고 하면 정말 독이 된다는... -_-
지금 개발중인 시스템도 총 9개의 프로젝트로 나뉘어져 있는데...
이게 정리가 안되서 컴파일이 제대로 돌아가지를 않는다.
허허..

먼저 프로젝트의 레퍼런스와 J2EE Module Dependency는 프로젝트 폴더에서 오른쪽 버튼을 누르고 "Properties"를 보면 나온다.

1. Project Reference
이건 간단하게 생각해서 ClassPath에 넣느냐 마느냐를 결정하는것으로 보면 된다.
현재 프로젝트를 빌드하고자 할때, 다른 프로젝트의 class가 필요한 경우 Project Reference로 지정하면 컴파일시에 그 프로젝트를 참고하여 빌드한다.

2. J2EE Module Dependency
이건 JEE 애플리케이션에만 해당한다.
EAR 프로젝트에서 WAR와 EJB 프로젝트를 레퍼런스할때, 컴파일은 되겠지만 EAR 프로젝트에는 실제 WAR와 EJB 파일들이 패키징시에 같이 디렉토리 구조에 맞춰 들어가야 한다.
이렇게 같이 패키징이 되도록 정의하는 것이 J2EE Module Dependency이다.

이 구조를 정의할때, 환형 참조 구조가 안되도록 정의하는것도 중요한 일...

빌드 스크립트 한번 올리기 되게 어렵다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

이제는 Trac

ALM/Build Automation (빌드 자동화) | 2008. 1. 24. 13:48 | Posted by 조대협

허드슨 테스트는 끝났고. 이제 서버에 이행 설치만 하면된다.
다음주에 C과장 오면 그쪽 프로젝트 업데이트 해서 서버에 설치하고 배포 START UP 스크립트 구성하고 테스트들 구성 추가해주면 될테고.

오늘부터는 TRAC설치다.
http://sourceforge.net/projects/traconwindows/
여기에 쉬운 설치 방법이 있어서 참고~~

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

통합 빌드 환경 설정 완료  (0) 2008.02.05
Code Coverage Tools  (0) 2008.02.01
이제는 Trac  (1) 2008.01.24
Hudson  (0) 2008.01.22
Atlassian Bamboo  (0) 2007.11.08
일일 빌드에 대해서..  (0) 2007.10.17
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG Trac

댓글을 달아 주세요

  1. jerry 2008.01.25 23:19  댓글주소  수정/삭제  댓글쓰기

    재밌겠다... 부럽수~
    난 soa 플젝 spot 지원을 하는데... 먼 spot 이 그렇게 긴지 원
    차라리 full 로 드가면 재미나 있겠는데 쩝

Hudson

ALM/Build Automation (빌드 자동화) | 2008. 1. 22. 11:28 | Posted by 조대협

테스트를 JUnit으로 만들어서 단위 테스트가 아닌 기능 테스트로 진행하려고 하는데.
테스트를 빌드 자동화 툴을 이용해서 자동화 할 예정인데.
Hudson 이거 정말 물건이다.
사용도 쉽고, 대부분의 빌드/테스트에 사용되는것들이 다 지원이 되니..
물건이네.
http://hudson.gotdns.com/wiki/display/HUDSON/Home

Corbertura도 플러그인으로 지원이 되는데.. 이걸 해..? 말아?

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

Code Coverage Tools  (0) 2008.02.01
이제는 Trac  (1) 2008.01.24
Hudson  (0) 2008.01.22
Atlassian Bamboo  (0) 2007.11.08
일일 빌드에 대해서..  (0) 2007.10.17
하나의 소스를 여러 환경에 DEPLOY하는 방법  (0) 2007.08.24
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG Hudson

댓글을 달아 주세요

프로젝트 자동화 도구..

ALM | 2008. 1. 18. 11:49 | Posted by 조대협
작년 7월 부터인가?
개발 자동화에 대해서 이것 저것 찾아봤다.
이런것 저런것 사용도 해보고 프로젝트에 적용도 해보고..
사용했던것중에서 이슈 트랙킹 시스템의 장점에 대해서는 완전 감동....

소스 관리는 SVN이 제일 나은것 같고.
빌드 자동화는 그동안 AntHill이나 Cruise Control이 대세 였으나..
이번에 Sun에서 HudSon이라는 것이 나왔네.
장점이 인스톨이 매우매우 쉽고... 다른 솔루션과 연계가 가능하다는것.

이슈 트랙킹인
다들 잘 아는 JIRA 이건 좋긴 한데.. 사용이고.
Bugzila 정말 힘들게 깔았는데. 인스톨이 힘들고 버그 트랙킹에만 국한 된다. 인터페이스도 약간 불편한듯하고..
Mantis는 인스톨이 쉽고 UI도 직관적이라서 이번 프로젝트에 적용해볼까 했는데.
Trac이 SCM (소스 관리) 및 프로젝트 관리도 가능하고. 마일스톤 관리등이 좋다는 장점이 있지만 인스톨과 운영이 쉽지 않아서 고민중이다.

테스트 커버러지와 단위 테스트를 몇달을 고민하고 시간 나는데로 테스트해봤는데.
이제야 감이 좀 잡히는듯.
기본적인 JUnit과 DAO테스트를 위한 DBUnit 이것들은 J2EE에 필수요소라 판단되고
J2EE테스트를 위한 InContainer 테스트 프레임웍인 Cactus
그리고 성능 테스트를 위한 Japex
코드 커버러지를 위한 Cobertura

이제 이것들을 유기적으로 결합하여 하나의 개발 프레임웍을 만들어야 하는데.. 사실 시간이 없고 프로젝트 관리할 수 있는 기회가 적어서 어디까지 만들어볼 수 있을까 걱정은 좀 된다.

이상적으로 구상중인것이

SVN+Hudson+Trac
빌드 스크립트로 ANT + MAVEN
테스트로는 JUnit,Cactus,Cobertura,DBUnit,Japex 요렇게 생각하고 있다.
금년에는 이쪽을 좀 정리해볼 생각인데...
워낙 환경이 고도화 된것이라서 설정 및 테스트 하는것도 쉽지는 않을 것 같고.
무엇보다 위에 내용들을 유기적으로 결합하여 프로세스를 잘 만들어내는 것이 관건이다.

P.S. 혹시 이쪽에 관심 있으시거나 경험 있으신분들은 경험 공유들 부탁드려요..



'ALM' 카테고리의 다른 글

빌드 자동화 연동에 대한 고민  (0) 2008.02.29
개발환경 자동화 환경  (5) 2008.02.28
프로젝트 자동화 도구..  (3) 2008.01.18
Dependency 분석 도구  (0) 2007.11.05
XPlanner  (0) 2007.10.23
WLW 10.1 (Flex 지원)  (2) 2007.10.09
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 짱가 2008.01.18 13:53  댓글주소  수정/삭제  댓글쓰기

    지금까지 여러 비교 자료들을 계속 읽어보면서 정말 많은 도움이 되고 있습니다.
    제 스스로도 하고 싶었던 작업을 조대협님께서 깔끔하게 정리해주시는 것이
    정말 좋습니다.
    많은 도움이 될 것 같습니다.
    감사합니다.

  2. 치요 2008.02.19 23:03  댓글주소  수정/삭제  댓글쓰기

    현재회사에서는 CVS만 사용하다 - > SVN/MANTIS연동해서 사용중입니다
    둘이 연동해서 이슈를 관리해가며 코드관리하는것이 꽤나 신기하더군요

    현재 CVS와는 다른 태깅과 데일리 빌드 같은 개념이 꽤나 생소해서
    꽤나 고생중이지만 어찌어찌해서 ANT로 자동 빌드 환경까지는 구성해서 사용중입니다. jUnit이나 DBUnit까지는 생각하고 있었는데 대협님 페이지에 와서
    Hudson 은 처음 알게 되었네요. 일단 maven연동까지는 해볼생각이구요
    Hudson은 천천히 배워가며 적용해봐야 겠네요
    아... 역시 이럴때마다 영어공부해야겠다는 생각이 ... ㅜㅜ

  3. 조대협 2008.02.20 08:22  댓글주소  수정/삭제  댓글쓰기

    차요//Hudson은 생각보다 사용방법이 쉽고 직관적이라서 운용해보시는 것을 추천합니다. 인스톨도 매우 쉽구요... 프로젝트에 적용해봤는데 반응이 괜찮습니다.

Cobertrua의 분석 리포트를 보면 Line Coverage율과, BranchCoverage율이 나오는데.
이 값이 정학하게 나오지 않고 N/A로 나오거나, 100%로 나오는 경우가 있는데
이건 클래스를 컴파일할때 디버깅 모드로 컴파일하지 않아서 발생하는 문제이다.
이를 해결하기 위해서
ANT TASK에서 <javac debug="true"...> 옵션을 추가해주면 된다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Cactus에서 이미 만들어놓은 JUnit 케이스를 재활용할 수 있는데.
만들어놓은 JUnit을 서버로 올려서 TestRunner를 이용하여 브라우져에서 실행하면 그대로 실행된다.

만약 ANT TASK에서 호출하고자 할때는 기존 JUnit케이스를 다음과 같이 ServletTestCase로 묶어야지 호출이 가능하다.
==

Cactus is able to run pure JUnit TestCase on the server side. This is done by using the ServletTestSuite Test Suite that wraps your existing Test Cases. For example:

public class TestJUnitTestCaseWrapper extends TestCase
{
    public static Test suite()
    {
        ServletTestSuite suite = new ServletTestSuite();
        suite.addTestSuite(TestJUnitTestCaseWrapper.class);
        return suite;
    }

    public void testXXX()
    {
    }
}
==

* addTestSuite(원래JUnitCase.class)를 하면 된다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 조대협 2008.03.06 21:47 신고  댓글주소  수정/삭제  댓글쓰기

    <target name="cactus-test">
    <echo> cactus URL = ${cactus.contextURL} </echo>
    <junit>
    <classpath>
    <path refid="cactus.classpath" />
    <path refid="master.classpath" />
    <pathelement location="${build.dir}"/>

    </classpath>
    <sysproperty key="cactus.contextURL" value="${cactus.contextURL}" />
    <formatter type="brief" usefile="false"/>
    <formatter type="xml"/>
    <batchtest todir="${project.dir}">
    <fileset dir="${test.src.dir}">
    <include name="**/*Wrapper.java"/>
    </fileset>
    </batchtest>

    </junit>
    <junitreport todir="${project.dir}">
    <fileset dir="${project.dir}" includes="TEST*.xml"/>
    <report todir="${project.dir}" format="frames"/>
    </junitreport>
    </target>

  2. 조대협 2008.03.06 21:47 신고  댓글주소  수정/삭제  댓글쓰기

    <sysproperty>에 URL넣는것 주의할것!!

서버쪽에서 Cobertura를 이용한 커버러지 분석을 할때
주의할점은

Cobertura는 기본적으로 ASM을 이용하여, 테스트를 진행할 코드에 커버러지 분석 코드를 삽입하는 방식이다. (AOP와는 다르게 STATIC한 방식을 사용)
그렇기 때문에, Instrumented 된 코드가 반드시 실행되도록 클래스패스에 삽입 하거나 또는 패키징 할때 Instrumented 되지 않은 코드를 WEB-APP에 먼저 복사한후 그 다음에 Instrumented된 코드를 복사하여 Overwrite가 되게 해야 한다.

그리고, Cobertura는 커버러지 분석한 정보를 메모리에 담아 놨다가 서버가 shutdown될 당시에 한꺼번에 파일에 쓰기 때문에 메모리 요구량이 높을 수 있다.
그래서 각 단위 테스트마다 리스타트를 해서 메모리가 오버 되지 않게 유지 해야 한다.

기동 스크립트에서는
JAVA에 -D 옵션으로 -Dnet.sourceforge.cobertura.datafile=파일명.ser 로 지정하고
Cobertura에서 사용하는 파일들 corbertura.jar, asm, asm-tree, jakarta-oro.. jar들을 클래스 패스에 삽입해야 한다.

이렇게 하고 Instrumented된 코드를 수행하면, (비단 JUnit이 아니더라도) 수행한 내역을 *.ser 파일에 저장하게된다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 2012.01.17 10:03  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

Cactus 테스트시 주의 할점

ALM/Test Automation | 2008. 1. 17. 10:12 | Posted by 조대협
1.  junit/framework/Test 클래스를 못 찾는 문제
${ANT_HOME}/lib 디렉토리에 junit.jar 파일을 복사해 놓아야 한다.

2. cactus ant task 실행시 테스트 케이스를 못찾고 ClassNotFoundException 이 나오는 문제
<cactus> 태스크 내에.. 
 <classpath>
    <pathelement location="${build.dir}" />
  </classpath>
로 지정한다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

JUnitPerf

ALM/Test Automation | 2008. 1. 16. 11:59 | Posted by 조대협
==

Decorate with style

Decorators aren't limited to a single decoration. For example, in Java™ I/O, it is possible to decorate a FileInputStream with an InputStreamReader with a BufferedReader (just remember this: BufferedReader in = new BufferedReader(new InputStreamReader(new FileInputStream("infilename"), "UTF8"))).

Decoration can happen on multiple levels, and so it is with JUnitPerf's TimedTests and LoadTests. When these two classes decorate each other, it leads to some compelling test scenarios, such as one where a load is placed on a business case and a time threshold is also applied. Or we could just combine the previous two test scenarios as follows:

  • Place a load on the testCreate() method.
  • Specify that every thread must finish within the time threshold.

Listing 4 shows what happens when I apply the above specifications by decorating a normal Test with a LoadTest, which is decorated by a TimedTest:


Listing 4. A decorated load and timed test
public static Test suite() {
 int users = 10;
 Timer timer = new ConstantTimer(100);
 long maxElapsedTime = 2000; 	 
 return new TimedTest(new LoadTest(
   new WidgetDAOImplTest("testCreate"), users, timer), 
     maxElapsedTime);  		
}

As you see, the testCreate() method is run 10 times (each thread launching 100 milliseconds apart), and each thread must complete within two seconds or the entire test scenario will fail.

출처 : Tong - exospace님의 JAVA통
==
위와 같은 방식으로, 기존 JUnit Test case를 Thread수, Thread당 수행 시간, 허용가능 응답시간으로 나눠서 테스트가 가능함.

대신 리포팅 기능이 약한데.
Japex는 리포팅 기능이 매우 강력한 반면, 허용 가능 응답시간이 없는것이 단점.

'ALM > Test Automation' 카테고리의 다른 글

Cobertura를 이용한 커버러지 테스트시 주의할 사항  (1) 2008.01.17
Cactus 테스트시 주의 할점  (0) 2008.01.17
JUnitPerf  (0) 2008.01.16
단위 테스트 1회 (JUnit)  (1) 2007.11.23
Test Coverage 분석툴  (0) 2007.11.08
Cactus 실행용 ANT 스크립트  (0) 2007.09.13
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG JUnitPerf

댓글을 달아 주세요