달력

102020  이전 다음

  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

'TSS'에 해당되는 글 2건

  1. 2008.11.28 변화, 그리고 적응 (2)
  2. 2008.11.01 오픈소스는 얼마나 테스트케이스가 많을까 (4)

변화, 그리고 적응

낙서장 2008. 11. 28. 23:26
요즘은 okjsp 트래픽이 많아져서 고민입니다. MySQL DB에서 처리시간이 지연되어서 connection pool이 100까지 차는 경우가 종종 생기는군요. "사이트 느리면 사람들 떨어져 나가겠지, 그래서 일정한 수를 유지하겠지."라고 애써 생각해보지만, 한편으로는 맘이 편하지 않습니다. ^^; 물론 요즘은 티스토리에 블로깅하느라 okjsp 사이트에 컨텐츠 올린지 굉장히 오래되었지만 말이죠.

왼쪽 메뉴를 바꿔보았습니다. 40개가 넘는 게시판이 있는데, 골고루 노출되는 효과가 있는 듯 합니다. 그리고 상단의 메뉴를 걷어내기 위한 포석이기도 합니다. 점점 네이트톡과 다름없이 기술은 없고 처세술만 난무하는 듯 해서 통로를 바꿨습니다.


IP를 막고 금지단어를 추가해서 사이트 (게시)물관리를 해봅니다만 플랫폼 자체의 통로도 사이트 색깔을 만들어가는데 중요한 요소라는 생각이 듭니다. 욕심 같아서는 TheServerSide.com 처럼 만들어 가고 싶군요.


새로운 기술에 대한 좋은 정보채널이라 생각하기 때문이죠. ^^
변화, 적응이라는 과정이 필요하지만 성장을 위한 것이라고 생각합니다.
(방문객에게는 조금 미안합니다. ^^; 익숙하지 않은 것에 대한 답답함 때문이랄까요.)
Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. 에코지오  댓글주소 수정/삭제 댓글쓰기 2008.12.02 10:56 신고

    음.... 요즘은 어느 개발관련 사이트든 기술에 대한 글이 뜸한거 같습니다.
    TSS도 마찬가진거 같구요.
    옛날엔 저도 okjsp에 글좀 올렸는데 말이죠.... 지금은..쩝... 반성 중... -.-;;
    이게 다 블로그 때문일까요? ㅎㅎ
    ps. 두번째 이미지가 안보이네요?

최근 TSS에 재밌는 기사가 하나 떴습니다. 테스트케이스가 공식적으로 개발과정에 포함되는지 아니면 비공식적으로 만들어지는지에 관한 조사였습니다. 2006년에 이어서 2년 후인 2008년 설문을 진행했습니다. 데이터는 다음과 같습니다.

Answers 2008 (2006)
Unit testing is not performed: 17% (13%)
Unit testing is informal: 40% (46%)
Unit tests cases are documented: 9% (11%)
Unit tests cases and their executions are documented: 14% (16%)
We use a Test Driven Development approach: 20% (14%)

Participants: 384 (2006: 460)
Ending date: October 2008 (February 2006)
Source: Methods & Tools (http://www.methodsandtools.com/)

TDD 접근법을 사용하는 것은 20%로 증가한 것에 비해 단위테스트에 대한 노력은 오히려 감소했습니다. 그리고 의외인 것은 외국에서도 아직 단위테스트가 보편적이지 않다는 것이었습니다.

오픈소스 프로젝트 하나를 앞서 살펴봤습니다. 여기에는 test라는 테스트케이스를 모아놓은 폴더가 있었습니다. 소스의 양은 얼마나 될까요. httpunit 이라는 단위테스트용 프로젝트이기 때문에 좀 더 많이 있을 거라 예상했습니다.
예상대로 제가 회사에서 만든 테스트코드들과는 비교할 수 없이 많더군요.

요기까지가 패키지 하나에 들어있는 소스 코드들입니다. 이 코드들을 테스트하는 테스트케이스는 다음과 같습니다.
그리 많은 것은 아니지만 대략 1/5 정도 테스트케이스의 클래스들이 있지않나 생각됩니다. 각 테스트케이스 내의 테스트 메소드들이 애플리케이션에 대한 코드 커버리지를 책임지겠지요.

테스트케이스를 모아놓은 것이 테스트스위트입니다. *Suite.java 로 찾아보면 다음과 같은 스위트들이 보입니다.

빌드 스크립트에서도 테스트 관련 배치작업을 찾을 수 있습니다.



test 타겟을 실행해보니 다음과 같은 결과가 나오는군요.
test:
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .....................................F....
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .........................................
     [java] .....................................
     [java] Time: 22.656
     [java] There was 1 failure:
     [java] 1) testCookieAge(com.meterware.httpunit.cookies.CookieTest)junit.framework.AssertionFailedError: cookie2 expiration expected:<1223798608260> but was:<1112124642000>
     [java]  at com.meterware.httpunit.cookies.CookieTest.testCookieAge(CookieTest.java:202)
     ...
     [java]  at com.meterware.httpunit.HttpUnitSuite.main(HttpUnitSuite.java:49)
     [java] FAILURES!!!
     [java] Tests run: 775,  Failures: 1,  Errors: 0
BUILD SUCCESSFUL
Total time: 36 seconds

디버깅을 할 것은 아니지만, 이렇게 테스트케이스를 775가지 이상 갖고 있는 애플리케이션을 관리하는 것은 좀 더 수월하지 않을까 생각됩니다. 작업환경의 차이에서 발생하는 버그도 찾을 수 있고, 코드 변경으로 인한 틀어짐도 놓치지 않기 때문입니다.

읽어주셔서 감사합니다. 알찬 11월 되시길...
Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. coolengineer  댓글주소 수정/삭제 댓글쓰기 2008.11.01 13:01

    http://blog.davebouwman.net/2008/06/04/DeveloperSurveyUnitTestingAmpOtherTools.aspx

    연관글을 따라가다 보니 재밌는 서베이가 있군요..

  2. 정의의소  댓글주소 수정/삭제 댓글쓰기 2008.11.01 13:11

    Test Case가 많은 Coverage를 가질 수록 코드 변경에 대한 자신감이 생기죠.. 최소한 이 Coverage에는 문제가 없다는... 그러나 Unit Test 를 단지 품질적인 측면만 보면 도입이 꺼려지지만 향후 생산성.. 파생되는 과제들(저희 회사의 경우)을 생각하면 나중에 다 많은 위력을 발휘하는 것 같습니다. - Unit Test 예찬론자... ^^: