'테스트 주도 개발'에 해당되는 글 2건

  1. 2007/09/25 HttpUnit: 웹 사이트에 대한 단위 테스트 프레임워크 (3)
  2. 2007/09/23 TDD를 사용한 개발 절차 (4)
Extremely Agile/TDD2007/09/25 02:00
방금 웹 서핑을 하다가 HttpUnit에 대한 글을 잠깐 읽었습니다. 블로그들에는 없는 내용이 없군요 :-P

http://httpunit.sourceforge.net/

위의 URL이 httpunit의 주소입니다. jUnit과 함께 사용해야하는, Java 기반의 solution입니다.

Cookbook 문서를 읽어보면 알수 있는 것입니다만 (아래의 글은 Cookbook 문서를 보고 간단히 요약한 것입니다) HttpUnit 프레임워크는 WebConversion 클래스를 사용해서 웹 브라우저가 만드는 HTTP conversion을 흉내냅니다.

WebConversation wc = new WebConversation();
WebRequest     req = new GetMethodWebRequest( "http://www.meterware.com/testpage.html" );
WebResponse   resp = wc.getResponse( req );

WebResponse 객체를 받아온 다음에는 getText() 메소드를 불러서 텍스트 형태의 프로세싱을 할 수도 있고, getDOM() 메소드를 호출해서 DOM 기반의 조작을 할 수도 있습니다. (이 편이 좀 더 편하긴 하겠네요.)

다음 처럼 하면 링크를 따라가는 것도 가능합니다.

WebConversation wc = new WebConversation();
WebResponse resp =
            wc.getResponse( "http://www.httpunit.org/doc/cookbook.html" ); // read this page
WebLink link = resp.getLinkWith( "response" );                              // find the link
link.click();                                                                               // follow it
WebResponse jdoc = wc.getCurrentPage();                                  // retrieve the referenced page

폼 프로세싱이나 테이블 형태의 자료 처리도 가능합니다. 폼 프로세싱 예제만 살펴보면,

WebForm form = resp.getForms()[0];      // select the first form in the page
assertEquals( "La Cerentolla", form.getParameterValue( "Name" ) );
assertEquals( "Chinese",       form.getParameterValue( "Food" ) );
assertEquals( "Manayunk",      form.getParameterValue( "Location" ) );
assertEquals( "on",            form.getParameterValue( "CreditCard" ) );

위와 같이 해서 폼의 기본 파라메타 값이 어떻게 만들어져있는지 검사할 수도 있고,

form.setParameter( "Food", "Italian" );      // select one of the permitted values for food
form.removeParameter( "CreditCard" );         // clear the check box
form.submit();                                // submit the form

폼에 포함된 컨트롤들에 값을 넣어서 날릴 수도 있습니다.

웹 기반의 인터페이스 테스트를 하는 데 굉장히 유용할 것 같네요. :-) 하지만 이 프레임워크의 가장 큰 약점은...

자바스크립트 지원이 아직은 기본적인 수준이다

는 점이 되겠군요 -_-;


다들 알고 있는데 저만 모르는 사실들이 아주 많은것 같아 좀 우울합니다 ㅋㅋ





Posted by 이병준

TRACKBACK http://www.buggymind.com/trackback/50 관련글 쓰기

댓글을 달아 주세요

  1. 시월애

    잘보고갑니다. ^^
    많은도움얻고갑니다 ㅎ

    2008/03/24 13:38 [ ADDR : EDIT/ DEL : REPLY ]
  2. 이것은 위대한이며 많은 사람들이이 공유를 주셔서 감사합니다 사랑 할거야 확신

    2011/11/22 04:12 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/TDD2007/09/23 20:45

아래의 그림은 TDD를 사용한 개발을 수행하는 절차를 요약하고 있습니다.

원본은 여기에 링크 걸어둔 PDF 파일에 나옵니다. 하도 예전에 다운받아둔거라 언제 받았는지도 기억이 잘 나질 않습니다만, PDF 파일을 열어 보면 어디서 다운받은 것인지는 나오는군요. :-) 참고하시기 바랍니다.

나온지 좀 오래된 자료이기는 합니다만, TDD의 개발 절차라는 것이 TDD 개념이 등장한 이래로 그렇게 많이 바뀌거나 하지는 않았습니다. 코드 작성 전에 테스트를 먼저 한다, 는 원칙은 그대로 있고, 그 적용에 따르는 세부사항만 좀 바뀐 정도일텐데, 그 나마 큰 변화가 있는 것 같지는 않아요.


사용자 삽입 이미지



절차는 간단히 요약하면 이렇습니다.
  1. 테스트 리스트를 만듭니다. (어떤 테스트를 수행할 것인지 협의하는 과정에서 나옵니다. 사용자 스토리를 만드는 과정에서 도출되는 일이 많습니다.)
  2. 다음의 3~7까지를 계속 반복합니다.
  3. 테스트 리스트에서 테스트 하나를 고릅니다.
  4. 우선, 컴파일조차 되지 않는 테스트 코드를 작성합니다. (컴파일이 되지 않으니 테스트를 아예 할 수가 없습니다.) [위의 다이어그램에서는 위에서 두 번째 줄의 왼쪽에서 두 번째 박스]
  5. 대충 뜯어 고쳐서 컴파일은 되도록 만듭니다. 테스트는 당연히 실패할 것입니다.
  6. 그런 다음, 우선 테스트가 통과되도록 만듭니다. (테스트가 통과되도록 만드는 것이 목적이니, 코드에 hardwired 된 로직이 존재해도 아직은 상관이 없습니다. 가령, 3이라는 반환값을 요구하는 테스트라면, 함수 안에서 그냥 3을 리턴해도 이 단계에서는 상관이 없다는 말입니다.
  7. 그런 다음 리팩토링(refactoring)을 시작합니다. 리팩토링을 해나가면서 중복을 제거하고, 말이 안되는 부분을 하나씩 말이 되도록 만듭니다. 리팩토링은 '아주 작은 단위'의 코드 변경입니다. 코드가 변경될 때 마다 컴파일하고 테스트를 돌려서, 그 리펙토링이 테스트를 fail시키지 않는지 확인해야 합니다. fail시켰다면, 너무 작은 리팩토링을 시도했거나, 잘못된 리팩토링 - 즉, 논리적인 오류를 발생시킨 리팩토링을 했다는 뜻입니다. 위의 그림에서는 '리팩토링'->'테스트' 사이의 순환 관계가 명시적으로 드러나지는 않습니다만, 리팩토링과 테스트는 반복적으로 계속해서 해나갈 수 있습니다.
뭐, 그림 자체는 그런 뜻입니다. :-) 그럼 테스트는 대체 어떻게 만드느냐.

이상적으로 보자면 테스트가 '개발될 모듈이 가져야 할 이상적인 인터페이스'에 근거해서 만들어지는 게 가장 좋겠지만, 그렇게 하자면 머리속에 '개발될 모듈의 형태'가 우선 잡혀야 합니다.

TDD 개발 과정에 대한 책 ("테스트 주도 개발") 을 보신 분이면 아시겠지만 테스트는 고정적이 아니며 항상 변화합니다. 개발될 모듈의 형태가 어떠할 지 완벽하게 미리 예측하는 것이 불가능하기 때문입니다. 테스트를 하고, 중복을 제거하고 리팩토링을 하다보면 개발중인 클래스가 개발자가 예측한 것과 조금은 다른 방향으로 흘러가게 되는 일도 생길 수 있고 (물론 가급적 그렇게 되지 않는 것이 좋겠지만 말입니다) 다른 식으로 구현을 가져가는 것이 보다 효율적이겠다는 판단을 내리게 되는 일도 생길 수 있습니다.

그러니, 테스트를 '미리 잘 정돈하여 만들어두어야 겠다'는 생각은 버리는 게 좋겠습니다. '어떤 테스트를 해야 하느냐'는 고정적일 수 있지만, '테스트를 어떻게 해야 하느냐'는 것은 계속해서 달라질 수 있기 때문입니다.


Posted by 이병준

TRACKBACK http://www.buggymind.com/trackback/49 관련글 쓰기

  1. TDD 개발 절차  삭제

    2008/04/22 11:37TRACKBACK FROM 괜히 즐거움...▒▒ http://www.redef.pe.kr ▒▒

    TDD를 개발 작업에 본격적으로 도입을 시작했습니다. 그동안 문서만 읽고 정리하는 수준에 그쳤는데 이제 부터는 본격적으로 시작을 했습니다. 그런데 이게 만만치 않은게 귀차니즘이 자꾸 발동을 한다는게 문제군요...;; 아무리 귀찮더라도 앞으로는 꾿꾿하게 TDD를 이용한 개발 절차를 따를려고 합니다... 테스트 리스트를 만듭니다. (어떤 테스트를 수행할 것인지 협의하는 과정에서 나옵니다. 사용자 스토리를 만드는 과정에서 도출되는 일이 많습니다.) 다음의..

댓글을 달아 주세요

  1. TDD를 적용하기 위한 절차를 찾다가 발견하게 되었습니다. 많은 도움 얻고 갑니다...
    즐거운 하루되세요~^^

    2008/04/22 11:38 [ ADDR : EDIT/ DEL : REPLY ]
  2. TDD를 하면서 느끼는 것은 초보자 무리라는 것입니다. ^^ 제가 생각하기에는 그래요.
    일단 초보자는 상급자로부터 Requirement를 받기 때문에 상당히 제한적이고, 초반에 참여를 하더라도 경험이 적기 때문에 테스트 코드를 많이 못 만들어 내는 것 같습니다.
    또한, 초보자는 Refactoring을 해야할 때, Refactoring 자체에 대한 지식이 별로 없는 관계로 힘들고 때에 따라서 Design Pattern을 적용해야 할 때가 있는데, 그렇지 못 할 때도 있더군요. 또 Design Pattern을 몰라도 되지만, 바라던 최적화 코드는 그다지 나오지 않더라구요.

    하지만, 지속적으로 이렇게해서 개발경력을 쌓으면 무적이 될 것 같기도 하네요. 그래서 저도 TDD를 지향합니다.

    Rod Johnson의 인터뷰인가? 정확하게 기억나지는 않지만, 꼭 필요한 기술이라고 해서, 1. OFD(Oriented Framework Development), 2. DI & IOC, 3, TDD 등이 있었던 것 같네요.

    잘 읽고 갑니다.

    2008/06/11 15:05 [ ADDR : EDIT/ DEL : REPLY ]
    • 반갑습니다. 초보자에게 좀 무리일 수는 있습니다만, 그 과정을 통해 배우는 것이 많다는 점에서 긍정적일수도 있을 것 같습니다. 저는 TDD를 최근에야 접했는데, 제가 통상적으로 프로그램을 짤 때 거치는 과정과 많이 닮아있어 오히려 프로그래밍을 배우기 시작하는 초기에 배웠더라면 어땠을까, 하는 생각을 자주 했습니다.

      2008/06/12 14:30 [ ADDR : EDIT/ DEL ]