반응형

http://xper.org/LineReaderTdd/






LineReader TDD 동영상


LineReader를 테스트 주도 개발(TDD)로 만들어 나가는 과정으로, 김창준과 강규영이 직접 제작했습니다. 전체 상영 시간은 약 1시간 20분 가량 됩니다. 시청을 하실 때에는 윈도우즈 미디어 플레이어를 사용하시고, 되도록이면 전체화면 모드로 보세요. 

-- 김창준, 강규영 (2003년 7월)


동영상의 저작권은 김창준과 강규영에게 있으며, 허락없이는 재배포할 수 없습니다.

반응형
반응형





http://www.javajigi.net/display/OSS/TDD



TDD

Toggle Space Navigation Tree
Space Map

TDD와 JUnit을 이용한 테스팅 방법을 알아보고 효율적인 테스팅 방법에 대해 토의해봅시다.

오픈 소스 스터디

Table of Contents

Introduction

  • 개발자의 테스트 활동이 중요한 이유
    • 초기 단계에서 발견된 결함은 수정이 용이하다.
    • 개발 후기 단계에서 발견된 결함들을 수정하기에는 비용과 시간이 많이 소비되고,
      프로젝트가 실패될 확률이 높아진다.
    • 개발 단계에서의 효율적인 테스팅은 전체 프로젝트 시간을 감소시킨다.
  • 테스트의 종류
    • 단위테스트 : JUnit
      단위테스트는 단위 코드에서 문제 발생 소지가 있는 모든 부분을 테스트 하는 작업이다. 
      보통 클래스의 public method 를 테스트 한다. 
      좋은 단위 테스트란 모든 메서드를 테스트 하는 것이 아니라, 
      상식 수준의 확인을 통해 단위 코드가 의도한 대로 동작하는지 여부를 판단하는 단계이다. 
      이상적으로는 코딩전에 테스트 케이스를 작성하여 구현시 보조자료로 활용하는 것이 좋다. ( TDD의 기법 ) 
      단위테스트 후에 개발팀은 테스트를 프로젝트 테스트 스위트에 추가하여 매일 여러번 수행하고 모든 테스트를 항상 통과하게 해야 한다. 
      기회가 된다면 Code Coverage 를 하는 것이 좋은데 오픈소스로는 JCoverage 등이 있다.
    • 통합/컨테이너 내부 테스트 : Cactus
      좋은 단위 테스트는 시스템내의 복잡한 부분에 관계없이 클래스 내의 함수들을 검사하는 것이다. 
      단위 테스트는 가능한 의존성 없이 독립적으로 처리되어야 한다. 
      Mock Object 로 테스트를 하는 경우도 있지만, 
      Cactus 는 J2EE 컨테이너에 접근하는 방법을 제공한다. 
      컨테이너 안에서 코드 테스트가 가능하도록 하기 위해서 Cactus 는 상세하거나 또는 까다로운 
      실제와 같은 모형을(mock-ups) 개발자에게 제공한다. 
      이 방법은 실행되는 코드가 제품이 출시되는 환경에서 실행되기 때문에 또 다른 피드백 기준을 제공한다. 
      컨테이너 서비스와 상호 작용하는 단일 오브젝트 경우에 컨테이너 내부 테스트를 사용하여 간편한 단위 테스트를 할 수 있다.
    • 수락/기능 테스트 : HttpUnit
      기능 테스트는 전체 시스템이 의도한 바대로 동작하는 지를 검사하는 과정이다. 
      이 방법은 완성된 시스템을 고객으로부터 검사받는 방법이므로 수락 테스트라고도 한다. 
      기능 테스트는 구조적 기능에 대하여 어떤 프로그램의 기능에 대한 시험이며 진척 상태를 확인하고 
      이전의 테스트나 누락된 결점을 잡아내거나 미완성 또는 불완전한 부분에서 발생된 문제를 찾아내는 것이 중요하다. 
      수락 테스트는 고객에 의해 작성된다. 
      기능 테스트는 항상 100% 구현될 필요는 없으나 제품 출시 전에는 100% 수행 되어야 할것이다. 
      기능 테스는 종종 매우 구체적인 내용들을 테스트 하기도 한다. 
      아직은 통괄적인 수락 테스팅 툴은 나오지 않았고 Junit은 어떤 자바클래스에서도 수행될 수 있으나 
      수락 테스팅 도구는 특정 애플리케이션 요구에 따라 작성되어야 한다. 
      HttpUnit을 이용하면 테스팅 API를 이용하여 웹 리소스에 대한 호출과 응답 값 조회를 프로그래밍 할 수 있도록 한다.

TDD

자동화된 테스트로 개발을 이끌어 가는 개발 방식을 테스트 주도 개발이라 부른다. 
TDD는 분석 기술이며, 설계 기술이며, 개발의 모든 활동을 구조화하는 기술이다. 
작동하는 깔끔한 코드(clean code that works). 
이 핵심을 찌르는 한마디가 바로 테스트 주도 개발의 궁극적인 목표다.

테스트 주도 개발에서는 두 가지 단순한 규칙만을 따른다.

  • 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
  • 중복을 제거한다.

또한 위의 두 가지 규칙에 의해 프로그래밍 순서가 다음과 같이 결정 된다.

  • 빨강- 실패하는 작은 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다.
  • 초록- 빨리 테스트가 통과하게끔 만든다. 이를 위해 어떤 죄악을 저질러도 좋다.
    (죄악이란 기존 코드 복사해서 붙이기-copy and paste, 테스트만 간신히 통과할 수 있게끔 
    함수가 무조건 특정상수를 반환하도록 구현하기 등을 의미한다.)
  • 리팩토링- 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복들을 제거한다

TDD 따라해보기

  • MyProject 라는 프로젝트를 만들었다. 메뉴> New> Project
  • TestCase를 생성한다. 이클립스에서는 TestCase와 TestSuite의 기본 템플릿을 제공하고 있다.
    메뉴> New> Other을 누르면 다음과 같은 창이 뜬다.

  • 생성할 TestCase 파일 이름 및 테스트 대상 클래스를 입력한다. (①)
    만약 setup() 메소드나 teardown() 메소드를 사용할 때는 해당 체크박스를 선택한다. (②)

  • 다음이 생성되었다.

  • 할일 목록을 작성해보자. 작업을 끝낸 항목에는 표시를 하고,
    또 다른 테스트가 생각나면 할일 목록에 새로운 항목을 추가할 것이다.

  • 자, 그럼 구현을 하기 위해 어떤 객체가 있어야 할까?
    방금 이건 속임수다. 객체를 만들면서 시작하는 게 아니라 테스트를 먼저 만들어야 한다. 
    앞에서 언급한 TDD의 주기중 현재 단계는 빨강이다.
  • 그렇다면 어떤 테스트가 필요할까? 할일 목록을 보니 첫번째 테스트는 좀 복잡해보인다.
    작은 것부터 시작하든지, 아니면 손을 대지 않는 게 좋겠다. 이번엔 다음 항목인 곱하기를 보자. 
    대단히 어렵진 않겠지? 이걸 먼저 하는게 좋겠다.
  • testMultiplication이라는 테스트를 추가해보자.

  • 다음 코드를 돌리면 당연히 에러가 난다. 메뉴> Run As> JUnit Test

  • 할일 목록에 3가지를 추가한다.

  • 빨간 막대기를 가능하면 빨리 초록 막대기로 바꾸고 싶다.
    실행은 안 되더라도 컴파일만은 되게 만들고 싶은데, 가장 쉬운 방법이 뭘까? 
    이번 단계는 TDD주기에서 빨강에서 초록으로 넘어가는 과정이다.
  • 현재 네 개의 컴파일 에러가 있다.
    • Dollar 클래스가 없음
    • 생성자가 없음
    • times(int) 메서드가 없음
    • amount 필드가 없음
  • 네개의 컴파일 에러를 없앨 수 있는 가장 빠른 방법은 다음을 테스트 코드 아래 추가하는 것이다.


  • 당장의 목표는 완벽한 해법을 구하는 것이 아니라 테스트를 통과하는 것일 뿐이므로 최소한의 작업을 수행한다.

  • 테스트를 다시 실행해보자.

  • 드디어 초록색 막대가 나타났다. 하지만 아직 주기가 완성되지 않았으니까 서둘지 않는게 좋겠다.
    우리는 TDD의 주기중 빨강/초록을 넘었다.
  • 다음 단계는 리팩토링이다.코드를 다음과 같이 바꿔준다.

  • 테스트는 통과하고 테스트 막대 역시 초록색이다. 우리는 여전히 행복하다.

  • 이 단계가 너무 작게 느껴지는가? 하지만 기억하기 바란다. TDD의 핵심은 이런 작은 단계를
    밟아야 한다는 것이 아니라, 이런 작은 단계를 밟을 수 있는 능력을 갖추어야 한다는 것이다.
  • 5를 어디서 얻을 수 있을까? 이건 생성자에서 넘어오는 값이니 이걸 다음과 같이 amount 변수에 저장하면,

  • 그걸 time()에서 사용할 수 있다.
    인자 multiplier의 값이 2이므로, 상수를 이 인자로 대체할 수 있다.

  • 마지막으로 우리가 자바 문법을 완벽하게 알고 있다는 것을 보여주기 위해 *=연산자를 써주자.( 물론 중복을 제거하기 위해서다. )

  • 이제 첫 번째 테스트에 완료표시를 할 수 있게 되었다.

  • 마무리 - 우리는 다음과 같은 작업들을 해냈다.
    • 우리가 알고 있는 작업해야 할 테스트 목록을 만들었다.
    • 오퍼레이션이 외부에서 어떻게 보이길 원하는지 말해주는 이야기를 코드로 표현했다.
    • JUnit에 대한 상세 사항들은 잠시 무시하기로 했다.
    • 스텁 구현을 통해 테스트를 컴파일했다.
    • 끔찍한 죄악을 범하여 테스트를 통과시켰다.
    • 돌아가는 코드에서 상수를 변수로 변경하여 점진적으로 일반화했다.
    • 새로운 할 일들을 한번에 처리하는 대신 할일 목록에 추가하고 넘어갔다.

TDD의 특징

  • 격리된 테스트
  • 테스트 목록
  • 테스트 우선
  • 단언 우선
  • 명백한 데이터

TDD와 관련된 의문

  • 단계가 얼마나 커야 하나?
  • 테스트 할 필요가 없는 것은 무엇인가?
  • 좋은 테스트를 갖췄는지의 여부를 어떻게 알 수 있는가?
  • TDD로 프레임워크를 만들려면 어떻게 해야하나?
  • 피드백이 얼마나 필요한가?
  • 테스트를 지워야 할 때는 언제인가?
  • 프로그래밍 언어나 환경이 TDD에 어떤 영향을 주는가?
  • 거대한 시스템을 개발할 때도 TDD를 할 수 있는가?
  • 애플리케이션 수준의 테스트로도 개발을 주도할 수 있는가?
  • 프로젝트 중반에 TDD를 도입하려면 어떻게 해야 할까?
  • TDD는 누구를 위한 것인가?
  • TDD는 초기 조건에 민감한가?
  • TDD와 패턴의 관계는?
  • 어째서 TDD가 잘 동작하는가?
  • TDD와 익스트림 프로그래밍의 실천법 사이에는 어떤 관련이 있는가?

JUnit

▪ 다운로드 : http://www.junit.org/

JUnit 기본 클래스

1. TestCase 클래스 : 가장 간단하게 Junit을 사용하는 방법은 TestCase 클래스를 상속받은 클래스를 작성하는 것이다. 이 클래스에는 test로 시작하는 메소드만 나열하면 된다.

2. TestSuite 클래스 : testCase 클래스를 상속받은 클래스만을 사용하다 보면, 일부의 test 메소드는 간혹 실행하지 않고 싶거나 특정한 test 메소드만 실행하고 싶을 때가 생긴다. (①) 또는 Test 클래스를 한데 묶어서 한꺼번에 실행하고 싶은 경우(②)도 발생한다. 이때 사용하는 것이 바로 TestSuite이다.

3. Assersions

4. Fixture : 초기 값 설정 및 해제 - setUp(), teardown()


JUnit4.0에서의 변경사항

  • Test Annotation
    이전 버전에서 사용했던 TestCase를 대신에 org.junit.Test를 임포트하여 다음과 같은 형식으로 사용한다.
    • @Test public void functionName() { }
  • Expected Exception
    @Test Annotation은 "expected" 라는 파라메터를 option 으로 가지고 있는데
    이것은 Throwable의 서브 클래스들을 값으로 취한다.
    • @Test(expected= IndexOutOfBoundsException.class) public void empty() {
      new ArrayList<Object>().get(0); 
      }
  • Timeout
    @Test Annotation은 long형 파라메터를 통해 timeout을 설정할 수 있다.
    • @Test(timeout=100) public void infinity()
      Unknown macro: { for ( ; ; ); }
  • Fixture
    • setup - Before Annotation
      • import org.junit.Before;
        @Before public void functionName()
    • tearDown - After Annotation
      • import org.junit.After
        @After public void functionName()
  • Ignore Annotation
    때때로 일시적으로 테스트를 작동시키지 않을 때가 있는데 Ignore이라는 Annotation을 사용할 수 있다. 
    Ignore하는 이유를 옵션 파라메터를 통해 기록할 수 있다.
    • @Ignore("not ready yet") @Test public void something()

단위 테스트 지침 요약

일반 원칙

  • 망가질 가능성이 있는 모든 것을 테스트한다.
  • 망가지는 모든 것을 테스트한다.
  • 새 코드는 무죄가 증명되기 전까지는 유죄.
  • 적어도 제품 코드만큼 테스트 코드를 작성한다.
  • 컴파일 할 때마다 지역 테스트를 실행한다.
  • 저장소에 체크인하기 전에 모든 테스트를 실행해 본다.

자문해 봐야 할 사항

  • 이 코드가 옳게 동작한다면 어떻게 그것을 알 수 있는가?
  • 이것을 어떻게 테스트할 것인가?
  • ''''' 어떤 것이 잘못될 수가 있는가?
  • 이와 똑같은 종류의 문제가 다른 곳에서도 일어날 수 있을까?

좋은 테스트란?

좋은 테스트는 'A- TRIP' 해야 한다.

  • 자동적('A'utomatic)
    • 테스트가 혼자 실행되고 자신을 검증할 수 있어야 한다.
  • 철저함('T'horough)
  • 반복 가능('R'epeatable)
    • 모든 테스트가 어떤 순서로든 여러 번 실행될 수 있어야 하고, 그때마다 늘 같은 결과를 내야 한다.
  • 독립적('I'ndependent)
    • 확실히 한 대상에 집중한 상태여야 한다.
    • 환경과 다른 개발자들에게서 독립적인 상태를 유지해야 한다.
    • 어느 테스트도 다른 테스트에 의존하지 않는다.
  • 전문적('P'rofessional)
    • 좋은 설계를 위한 모든 일반적인 규칙, 캡슐화 유지, DRY 원칙 지키기, 결합도 낮추기 등은 제품 코드에서 그랬듯이 테스트 코드에서도 반드시 지켜져야 한다,

무엇을 테스트 할 것인가?

Right-BICEP (오른쪽 이두박근이라는 뜻)

  • Right - 결과가 옳은가?
    예) 
  • B - 모든 경계('B'oundary) 조건이 correct 한가?
    <경계 조건에서 확인해봐야 할 사항들 - 'CORRECT'>
    • 형식 일치('C'onformance) - 값이 기대한 형식과 일치 하는가?
      예) 최상위 도메인 이름이 없는 이메일 주소 fred@foobar 이 넘어온다면?)
    • 순서('O'rdering) - 적절히 순서대로 되어 있거나 그렇지 않은 값인가?
      예)
    • 범위('R'ange) - 적당한 최소값과 최대값 사이에 있는 값인가?
      예) 
    • 참조('R'eference) - 코드가 자기가 직접 제어하지 않는 외부 코드를 참조하는가?
      예) 
    • 존재성('E'xistance) - 값이 존재 하는가?
      예) null이 아님, 0이 아님, 집합 안에 존재함)
    • 개체 수('C'ardinality) - 확실히 충분한 값이 존재하는가? 개수를 정확히 필요한 만큼 갖고 있다던가, 정확히 필요한 만큼 만들었다는 것을 확인해야 한다.
      예) 울타리 기둥 에러, 하나 차이에 의한 오류
    • 시간 ('T'ime) (절대적으로 그리고 상대적으로) - 모든 것이 순서대로 일어나는가? 제시간에? 때 맞추어?
      예) 로그인하기 전에 문서를 출력하려고 시도하는 것
  • I - 역('I'nverse) 관계를 확인할 수 있는가?
    예) 
  • C - 다른 수단을 사용해서 결과를 교차 확인('c'ross-check) 할 수 있는가?
    예) 
  • E - 에러조건('e'rror condition)을 강제로 만들어 낼 수 있는가?
    현실 세계에서는 에러가 발생한다. 여러분은 강제로 에러를 일으켜 코드가 현실 세계의 문제를 제대로 처리한다는 것을 테스트 할 수 있어야 한다. 
    네트워크 에러 등을 시뮬레이션 하는 경우 모의객체(mock object)를 사용할 수 있다.
  • P - 성능('P'erformance) 특성이 한계 내에 있는가?
    예) 

프로젝트에서 테스트하기

1. 테스트 코드를 어디에 둘 것인가?

  • 같은 디렉터리
    • 장점: TestAccont가 Account의 보호된 멤버 변수와 메서드에 접근할 수 있다.
    • 단점: 테스트 코드가 제품 코드 디렉터리의 공간을 잡아먹으면서 어질러져 있다.
  • 하위 디렉터리
    • 장점: 태스트 코드를 적어도 제품 코드와 똑 같은 디렉토리에 있지 않게 떨어뜨려 놓을 수 있다.
    • 단점: 테스트 코드가 다른 패키지에 있으므로 필요한 멤버들을 노출시키는 제품 코드의 하위 클래스를 사용하지 않는다면 테스트 코드는 보호된 멤버에 접근할 수 없다.
  • 병렬 트리
    • 장점: 테스트 코드와 제품 코드가 정말로 분리되었다. 테스트 코드가 같은 패키지에 있기 때문에 선택적으로 접근할 수 있다.
    • 단점: 편하게 쓰기에는 너무 멀리 떨어져버린 건지도 모른다.

2. 테스트 예절

  • 혼자하는 테스트와 다른 사람과 함께하는 테스트의 가장 큰 차이점은? 테스트 코드의 동기화
  • 팀 환경에서 코드를 체크인 할 때는, 그 코드가 단위 테스트를 완료하였고,모든 단위 테스트가 통과했다는 것을 확인해야한다.
    사실상, 전체 시스템의 코든 테스트가 새로운 코드에 대해 계속 통과해야 한다.
  • 잠재적 위반사항 목록을 만들자
    • 불완전한 코드(예: 클래스 파일 하나만 체크인 하고 그것이 의존할 수 있는 다른 파일은 체크인 하는 것을 잊어버린 경우)
    • 컴파일 되지 않는 코드
    • 컴파일 되기는 하지만, 다른 코드를 망가뜨려서 컴파일 되지 않게 만드는 코드
    • 대응하는 단위 테스트가 없는 경우
    • 단위테스트가 실패하는 코드
    • 자신의 테스트는 통과하지만, 시스템의 다른 테스트를 실패하게 만드는 코드

3. 테스트 빈도

  • 새 메서드를 작성할 때마다 지역 단위 테스트들을 컴파일하고 실행한다.
  • 버그를 고칠 때마다 버그를 드러내는 테스트를 시행한다.
  • 성공적으로 컴파일 할 때마다 지역 단위 테스트들을 실행한다.
  • 버전 관리 시스템에 체크인할 때마다 모든 모듈 또는 시스템의 단위 테스트들을 실행한다.
  • 따로 배정된 특정 컴퓨터가 자동으로 하루 종일(주기적으로, 또는 버전 관리 시스템에 체크인 할 때마다),
    처음부터 전체 빌드와 테스트를 수행하고 있어야 한다.

4. 테스트와 레거시 코드

  • 이미 있던 코드의 경우 : 가장 망가진 부분을 위한 테스트를 가장 먼저 추가하는 편이 좋다.
    이런 환경에서 실시하는 단위 테스트는 뒷걸음 질을 막는다. 
    즉, 유지 보수하기 위해 수정하고 개선하다가 이미 있는 부분들에 버그를 만들어 내는 죽음의 나선을 피할 수 있다.
  • 연속적 빌드-테스트 프로그램을 사용하여 코드가 저장소에 전송될 때마다
    자동으로 단위테스트가 실행되게 만든다면 불량코드가 전체 회사에 돌아다니는 일을 방지할 수 있다.

5. 테스트와 검토

  • 코드 검토를 수행할 때, 그 검토과정의 필수 구성요소로 테스트 코드를 끼워넣어라
  • 코딩과 검토를 다음 순서로 하면 좋다
  • 테스트 케이스나 테스트 코드, 둘 다를 작성한다.
    1. 테스트 케이스나 테스트 코드, 또는 둘 다를 검토한다.
    2. 테스트 테이스나 테스트 코드, 또는 둘 다를 검토할 때마다 수정한다.
    3. 테스트를 통과하는 제품 코드를 작성한다.
    4. 제품코드와 테스트 코드를 검토한다.
    5. 검토할 때마다 테스트 코드와 제품코드를 수정한다.
    6. 모든 팀원을 이 과정에 참여시킴으로써 팀의 의사소통을 증진시킬 수 있다.
      다른 이들이 어떻게 테스트 하는지, 팀의 규칙이 무엇인지 알게된다.

설계와 관련된 문제들

1. 테스트의 용이성을 높이는 설계

2. 테스트를 위한 리팩토링

3. 클래스의 불변성(invariant)을 테스트 하기

  • 구조적
    • 주문 정보 입력 시스템은 다음과 같은 불변성을 가질 수 있다.
      • 모든 개별 항목은 어떤 주문에 속해야 한다.
      • 모든 주문은 개별 항목 하나 이상을 가져야 한다.
    • 데이터 배열을 다룰 때 인덱스 노릇을 하는 멤버 변수는 다음과 같은 불변성을 가질 수 있다.
      • 인덱스는 >=0이어야 한다.
      • 인덱스는 < 배열 길이여야 한다.
  • 수학적
    • 은행 계좌의 입금 부분과 출금 부분을 계산하면 잔고와 맞아 떨어져야 한다.
    • 다른 단위로 측정된 양은 변환 후에 맞아떨어져야 한다.
  • 데이터의 정합성(consistency)
    • 쇼핑 카트에 들은 항목 목록, 전체 판매액, 그 쇼핑 카트에 들은 전체 항목 개수는 밀접한 관련이 있다.
      항목 목록의 구체적인 내용을 알면, 다른 두 수치를 이끌어 낼 수 있다. 이 수치들이 조화를 이루어 맞아 
      떨어진다는 사실은 불변성이 되어야 한다.

참고문헌

  • 이클립스 기반 프로젝트 필수 유틸리티 CVS,Ant,JUnit (민진우 & 이인선 공저, 한빛미디어)
  • 테스트 주도 개발 (켄트 벡 저, 김창준 & 강규영 역,인사이트)
  • 실용주의 프로그래머를 위한 단위 테스트 with JUnit (데이비스 토머스 & 앤드류헌트 공저, 이용원 & 김정민 역, 인싸이트)
  • 참고 싸이트 - TDD를 공부하고 싶다면?
    http://wiki.tdd.or.kr/wiki.py
    http://c2.com/cgi/wiki?TestDrivenDevelopment
    http://xper.org/wiki/xp/

문서에 대하여

최초작성자 : 오혜진
최초작성일 : 2006년 2월 19일
버전 : 1.0 ? ㅎㅎ 
문서이력 :

  • 2005년 2월 19일 오혜진 문서 최초 생성
  • 2005년 2월 20일 JUnit4.0에서의 변경사항 추가
  • 2005년 2월 21일 오픈소스스터디 1기 장회수님 자료 참고하여 보완, 테스트의 종류 추가
  • 2005년 2월 24일 프로젝트에서 테스트하기 항목 추가 및 문서 구조 수정

반응형
반응형

크리에이티브 커먼즈 라이선스
Creative Commons License
  Doxygen은 주어진 소스 코드를 분석하고 소스 코드에 있는 특정한 형식의 주석을 이용해서 소스 코드를 자동으로 문서화해주는 프로그램이다. 결과는 일련의 HTML 페이지들이구, LATEX나 PDF 문서들을 만들어낼 수도 있다.
 일단 Doxygen을 설치 하기 전에 아래와 같이 해당 문서에그래프 다이어그램도 만들기 위해서는 Graphviz의 Graph Visualization Software를 설치할 필요가 있다. 


이 사이트에 접을 하면 위와 같이 첫 화면에서 current stable release 부분에서 다운을 받을 수 있다.
 graphviz-2.26.3.msi 이라는 파일 이름으로 다운이 받아졌을 것이다. 다운 받고 아무 폴더에 깔아 주기만 하면 된다.

 Doxygen 설치 
이제 본격적으로 Doxygen을 설치해보자. 


위에서 보이듯이 Download 메뉴를 클릭하고 중간쯤에 다운 받을 수 있는 화면이 나온다 윈도우에서는 Doxygen Wizard로 문서화를 간편하게 할 수 있다. Wizard가 나오기 전에는 조금 사용하기 불편했던 모양이지만, 요즘에는 편의성이 많이 제공되고 있다. 
다운을 받았으면 원하는 폴더에 설치를 해주자. 본인은 \Tools\Doxygen 1.7.1 이라는 폴더에 설치를 했다. 

 Doxygen Wizard 
 설치를 끝마쳤다면, bin 폴더에 doxywizard.exe 파일을 실행 시켜 보자. 

아래는 실행 시킨 모습이다. 실행을 시켰으니 옵션들에 대해서 알아 보자. 우선 Wizard - Project 부분이다.
 - 1번 : 프로젝트 이름을 설정한다. 
 - 2번 : 소스 파일이 있는 디렉토리를 설정한다. 
 - 3번 : 문서화한 결과 html들을 넣을 Destination Directory를 설정한다. 

- 1번 : Include cross-refeenced source code in the output 옵션은 각 함수마다 사용한 함수 코드로 바로 Jump할 수 있는 링크를 생성해 준다. 즉, html 문서에서 링크를 타고 넘나 드는 것과 같은 효과를 나타낸다.
 - 2번 : Doxygen에서는 각 코드만의 고유 주석 스타일을 가지고 있는데, 이런 주석 스타일에 맞춰서 해당 언어에 맞는 것에 체크를 해주면 된다. 

 - 이곳은 자신이 출력하고자 하는 형식을 고르는 곳이다. 

 - Wizard의 마지막 부분인 Diagrams 부분은 다이어그램을 사용할 것인지 안할 것인지 설정하는 부분이다. GraphViz를 설치 했다면 이 다이어그램을 사용할 수 있다.

 - 이런 설정을 다 마쳤다면 Run Doxygen을 통해 문서화하고 결과물들을 뽑아 낼 수 있다.

 Doxygen 에서 한글은? 
 간혹 가다가 문서화 했을 시, 주석에 한글사용을 했다면 깨지는 경우가 있다. 아까 expert부분을 넘어 갔는데, 이 부분은 세세한 설정부분이 있어 까다롭지만, 다른 것은 몰라도 이 한글이 안깨지게 하는 법만 알면 된다. 아래 빨간색 네모친 부분만 바꿔주자.

 Doxygen, chm 파일 만들기 
 PDF와 같이 manual이나 그런곳에 자주 보이는 chm 형식으로 파일을 만들 수 있다. Wizard - Output 부분에 chm 부분을 체크 하면 된다. 허나 이 설정을 체크만 한다고 해서 다 끝나는 것은 아니다. MS HTML Help가 필요하기 때문이다. 만약 깔려 있다면 상관없지만, 안깔려 있다면 꼭 설치를 해주고 설정을 해줘야 한다. 

위의 다운로드 링크를 클릭해 다운받고, 어디에다가 설치 했는지 알아 두자 Doxygen Wizard의 설정도 바꿔줘야 하기 때문이다.

Expert - HTML 부분에서 중간쯤에 GENERATE_HTMLHELP 부분을 체크 한 후, HHC_LOCATION 부분에서 아까 설치한 HTML Help의 프로그램 경로를 지정해 준다.



http://www.stack.nl/~dimitri/doxygen/index.html


Doxygenlatest release v1.8.2 - last page update Sat Aug 11 2012
Doxygen Manual

Generate documentation from source code

Doxygen is a documentation system for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#, and to some extent D.

It can help you in three ways:

  1. It can generate an on-line documentation browser (in HTML) and/or an off-line reference manual (in $\mbox{\LaTeX}$) from a set of documented source files. There is also support for generating output in RTF (MS-Word), PostScript, hyperlinked PDF, compressed HTML, and Unix man pages. The documentation is extracted directly from the sources, which makes it much easier to keep the documentation consistent with the source code.
  2. You can configure doxygen to extract the code structure from undocumented source files. This is very useful to quickly find your way in large source distributions. You can also visualize the relations between the various elements by means of include dependency graphs, inheritance diagrams, and collaboration diagrams, which are all generated automatically.
  3. You can also use doxygen for creating normal documentation (as I did for this manual).

Doxygen is developed under Linux and Mac OS X, but is set-up to be highly portable. As a result, it runs on most other Unix flavors as well. Furthermore, executables for Windows are available.


Doxygen license

Copyright © 1997-2012 by Dimitri van Heesch.

Permission to use, copy, modify, and distribute this software and its documentation under the terms of the GNU General Public License is hereby granted. No representations are made about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. See the GNU General Public License for more details.

Documents produced by doxygen are derivative works derived from the input used in their production; they are not affected by this license.

User examples

Doxygen supports a number of output formats where HTML is the most popular one. I've gathered some nice examples of real-life projects using doxygen.

These are part of a larger list of projects that use doxygen. If you know other projects, let me know and I'll add them.

Commercial Support

I'm currently investigating the possibilities of providing commercial support for doxygen. The forms of support I'm thinking of are:

  • implementing features,
  • fixing bugs,
  • providing priority help in answering questions.

To get a better understanding of the feasibility, please let me know if you have a need for this type (or another type) of doxygen related commercial support.

Future work

Although doxygen is successfully used by large number of companies and open source projects already, there is always room for improvement.

You can submit enhancement requests in the bug tracker. Make sure the severity of the bug report is set to "enhancement".

Acknowledgements

Thanks go to:

  •  Malte Zöckler and Roland Wunderling, authors of DOC++. The first version of doxygen borrowed some code of an old version of DOC++. Although I have rewritten practically all code since then, DOC++ has still given me a good start in writing doxygen.
  • All people at Qt Software, for creating a beautiful GUI Toolkit (which is very useful as a Windows/Unix platform abstraction layer :-)
  • My brother Frank for rendering the logos.
  • Harm van der Heijden for adding HTML help support.
  • Wouter Slegers of Your Creative Solutions for registering the www.doxygen.org domain.
  • Parker Waechter for adding the RTF output generator.
  • Joerg Baumann, for adding conditional documentation blocks, PDF links, and the configuration generator.
  • Tim Mensch for adding the todo command.
  • Christian Hammond for redesigning the web-site.
  • Ken Wong for providing the HTML tree view code.
  • Talin for adding support for C# style comments with XML markup.
  • Petr Prikryl for coordinating the internationalization support. All language maintainers for providing translations into many languages.
  • The band Porcupine Tree for providing hours of great music to listen to while coding.
  • Andrea Schulte for translating part of the web page to German.
  • Jan Milz for mirroring the tar ball.
  • Techfacts.de for their long time contribution and support.
  • many, many others for suggestions, patches and bug reports.
Follow doxygen on Twitter Doxygen on freshmeat Doxygen on SourceForge 

This page was last modified on 11 August 2012. 
(c) 1997-2012 Dimitri van Heesch, first release 27 oct 1997.




독시전 사용법


초기 사용법


JAVADOC_AUTOBRIEF 옵션을 YES

Doxgen 에 대한 개인적인 생각, 굳이 안써도 된다는 의견

과거버전이긴 하지만 Doxgen syntax 에 관한 얘기가 있다.


doxgen 에 대한 여러가지 설명들

소스인사이트에 doxgen 주석 comment 추가

doxgen 주석에 관한 format template




출처 : http://acidlikk.tistory.com/entry/Doxygen에서-GraphVizdot로-Diagram-그리기



Doxygen에서 GraphViz(dot)로 Diagram 그리기

Posted 2007/11/28 14:59 by acidlikk
1. GraphViz(dot)을 설치한다. http://www.graphviz.org 에서 무료로 받을 수 있다.

2. Doxygen Wizard의 Diagrams 탭에서 Use dot tool from the GraphViz package to generate 선택. 그 밑의 체크박스는 취향에 따라...

3. Expert의 Dot 탭에서 설정을 해 준다.

먼저, DOT_PATH에 GraphViz의 dot이 깔린 bin 폴더의 절대 경로를 써준다. 예를 들어,

DOT_PATH: C:\Program Files\Graphviz2.16\bin

그리고 HAVE_DOT을 체크해준다. 나머지 체크박스도 취향에 따라...





반응형

'디자인패턴과방법론 > 개발방법론' 카테고리의 다른 글

LineReader TDD 동영상  (0) 2012.11.01
TDD 개발방법론  (0) 2012.11.01
단위테스트  (0) 2012.10.31
반응형





단위테스트란 무엇인가?

단위 테스트는 테스트 대상이 되는 코드 기능의 아죽은 특정 영역을 실행해 보는, 개발자가 작성한 코드 조각이다. 대개 단위 테스트는 특정 상황에서 특정 메서드를 시험해본다. 예를 들어, 어떤 정렬된 리스트에 큰 값을 넣고 이 값이 리스트 끝에 들어 있는지 확인해 볼 수 있다. 또 어떤 문자열에서 문자 패턴을 하나 지우고 그것이 없어졌는지 확인할 수도 있다.
 단위 테스트는 어떤 코드 조각이 개발자가 생각한 대로 동작하는지 증명하기 위해 수행하는 것이다.
 그 동작이 고객이나 최종 사용자가 바라는 것인지 아닌지는 해결되지 않은 채로 남는다. 이 부분은 인수 테스트의 목표다. 우리는 아직은 공식적인 유효성 검증과 확인이나 정확성에 크게 신경 쓰지 않는다. 이 시점에서는 성능 테스트에 조차 관심을 두지 않는다. 우리가 할 일은 단지 코드가 의도대로 동작하는지 확인하는 것이고, 따라서 코드의 기능 중에 아주 작고 고립된 부분만 테스트하기를 원한다. 개개의 부분들이 생각한 대로 동작한다는 확신을 쌓아 나감으로써, 비로소 그것들을 조립하여 전체 동작 시스템을 테스트하는 단계로 나아갈 수 있다.
 어쨌든, 만약 코드가 생각대로 동작한다고 확신할 수 없다면 어떤 형태의 테스트라 해도 그저 시간 낭비일 뿐이다. 여전히 다른 형태의 테스트도 필요할 테고, 환경에 따라서는 훨씬 많은 공식 테스트도 필요할 것이다. 하지만 자선과 마찬가지로 테스트는 기본에서 시작한다.


왜 귀찮게 단위 테스트를 해야 하는가?

무엇보다 시간은 금이다라는 말과 같이 단위테스트는 프로그래머의 삶은 편하게 해준다. 디버깅에 낭비하던 시간을 극적으로 줄여 준다.
 누군가 코드를 짤때 코드가 제데로 동작한다고 가정하고 개발을 하면, 그 이후에 코드가 제데로 동작하는지 확인 못한채 짜는 코드들은 문제는 늘어만 가게 된다. 어떤 코드 또한 돌아가지 않게 될 수도 있다. 처음에 짠 낮은 레벨의 코드가 문제가 생기면 그부분만 고친다고 해서 문제가 해결되는 것은 아니다. 이런 문제가 잇을 경우엔, 코드에 대한 확신을 얻어야 한다. 코드에게 무슨일을 하고 잇는지 물어봐야 하고 그 결과가 기대한 바와 같은지 확인해야 할 것이다. 이 간단한 개념이, 좀 더 나은 코딩을 위한, 가장 확실하고 가장 효과적인 기법인 단위 테스트의 핵심이다.

반응형

+ Recent posts