사례 연구
작성자 : 김형준
작성일 : 2003.07.08 ~ 2003.09.17
버 전 : 1.0
본 글의 배포는 자유롭지만 작성자의 수고를 생각해서 출처 및 저자는 표기는
반드시 해 주시기 바랍니다.(www.jaso.co.kr)
무단으로 상업적인 용도로 사용할 수 없습니다.
Copyright© 김형준(babokim@unitel.co.kr) All right Reserved
목 차
◆ 웹 어플리케이션 개발을 위한 Container Plugin 설치.. 7
3. TDD(Test Driven Development) 적용 예.. 37
☞ cactus 를 이용한 Servlet 테스트(Front Controller) 66
☞ 웹 레이어와 비즈니스 레이어 테스트 사이에 발생하는 코드의 중복.. 80
☞ 웹 계층과 비니지스 계층의 개발을 병렬로 개발할 경우의 테스트 방안.. 80
☞ cactus를 이용하는 경우 한글 처리 문제.. 80
글을 시작하기 전에:
이 글을 모두 쓰고 실제 아주 작은 프로젝트에서 TDD를 현재 사용하여 구현하고 있는데 이글에서 나타난 부분중에 여러가지 수정할 사항이 있음을 먼저 밝히고자 한다. 가장 큰 부분은 Service를 테스트하기 위해 Service에서 제공하는 하나의 기능에 대해 테스트 클래스를 만드는 것으로 설명하고 있는데 Service 클래스에 대해 하나의 테스트 클래스로 만드는 것이 더 좋을 듯 하다.
실제 필자가 TDD를 조금씩 적용해보니 이 글에서 나타나는 부분에 대해 보완 사항이 많이 있는 것 같아 조금씩 보완하는 글을 올려야 할 것 같다.
개발자들 사이에서 “프로그램 코딩 또는 시스템 개발”은 “노가다”라는 다소 자조적인 말을 많이 한다. 필자도 물론 이런 말을 가끔 하는 개발자 중에 한 사람이라고 할 수 있다. “노가다”라는 말에는 단순히 반복적이며 지루하고 누구나(??, 프로그램에 대한 조금의 지식만 있는 사람) 몸(체력)만 버텨주면 가능하다는 뜻이 숨어 있다.
국내의 개발 관련 프로젝트를 보면 이러한 “노가다”적인 의미와 아주 맞아 떨어지고 있다는 것이 프로그래밍을 본업으로 삼고 있는 필자를 우울하게 만들곤 한다. IT 강국이라고 외치고 있는 대한민국의 S/W 산업의 현실은 강국이라는 소리는 고사하고 후진성을 면치 못하고 있다라고 생각한다.
프로젝트의 비용절감을 기술을 통해서가 아니라 단순히 좀 더 값싼 개발자, 하도급 등을 통해 실현하려고 하는 데서 나타나는 문제점이 아닌가 생각한다.
현재의 프로젝트 상황을 한번 보면, 대부분의 프로젝트가 개발방법론이라는 틀 안에서 S/W를 개발하는 공정에만 너무 집중되어 있고 실제 제품이 되는 S/W의 코드는 관심 밖인 경우가 많다. 프로젝트의 인수 시에도 방법론에서 제시하는 산출물들이 모두 만들어 졌는지, 산출물들 간의 일관성은 유지가 되는지에 대해 더 많은 관심을 가지고 있고, 실제 S/W 코드를 들여 보고 확장성을 고려했는지, 산출물에서 제시한 코딩 가이드는 지켜졌는지에 대한 절차는 거의 없다라고 할 수 있다.
물론 사용자 측에서 인수를 하기 전에 충분히 테스트를 수행하는 경우도 있겠지만 이 경우도 기능이 제대로 구현되어 있는지, 빠진 기능은 없는지에 대한 단순 기능테스트에 불과하다고 할 수 있다.
또한 각각의 SI업체에서 수행하고 있는 품질활동이라는 것도 이러한 방법론적인 요소가 너무 강하다고 할 수 있다. 물론 방법론 상에도 구현 단계에서 코드 리뷰 라는 활동이 있다. 하지만 이 코드 리뷰 활동은 단순히 형식적이고 실제로 일정에 쫓겨 제대로 수행되는지도 의문이다.
이러한 공정, 산출물 보다 실제 제품이 되는 S/W 코드의 품질에 대해 어떻게 개발하면 좀 더 신뢰성 있고, 유지보수하기 수월하며 향후 확장성까지 고려한 코드를 만들어 낼 것인지에 대해 고민을 해야 하지 않을까???? 이것이 곧 S/W 개발에서의 기술이고 경쟁력이 되는 것이라고 생각한다.
물론 이전까지의 방법론에서 제시한 모든 사항을 준수하고 모든 활동들을 수행하면 S/W의 코드에 대한 검증도 되겠지만 현실은 어떠한가? 방법론의 산출물 따로 개발 따로 진행되어 온 것이 1 ~ 2년이 아니거늘 어느 개발자가 이러한 방법론의 이론적인 이상을 믿고 개발을 진행할 것인가?
이번 글에서는 자바 통합 개발환경(IDE, Integrated Development Environment)을 지원하는 eclipse를 실제 웹 어플리케이션 개발 환경에 적용해보고 신뢰성 있는 코드를 생산하기 위한 방법인 TDD(Test Driven Development)에 대한 실제 구현을 eclipse를 이용하여 적용하는 방법에 대해 설명하고자 한다.
이번 글에서 TDD의 이론적인 설명은 아직 필자도 TDD에 대해 많은 내용을 알지 못하기 때문에 어설프게 설명하느니 차라리 하지 않기로 하겠다. 이번 컬럼은 단순히 eclipse에서의 TDD 적용사례정도라고 생각하면 될 것이다.
TDD에 대한 이론적인 내용은 Kent Beck의 “Test-Driven Development
By Example”을 참고하기 바란다.
이번 글에서 설명하는 내용
- Eclipse : 자바 통합개발환경
- TDD : Test Driven Development
- JUnit : TDD를 지원하는 도구
- Cactus : JUnit을 확장한 apache의 프로젝트로 Servlet, EJB 등 Container상에서 운영되는 어플리케이션의 테스트를 지원하는 도구
2장에서는 주로 eclipse의 설치 및 환경 설정관련 사항, 사용Tip 등에 대한 설명만 있기 때문에 eclipse에 대한 사항을 알고 있으면 3장 TDD부분으로 넘어가기 바란다.
지금까지 자바 통합 개발 환경의 개발자들의 지지를 받지 못했다. 필자가 아직까지 이러한 개발도구를 시용하지 않았기 때문에 필자의 주관적인 생각일 수도 있지만 필자가 알고 있는 대부분의 개발자나 필자가 참여한 대부분의 프로젝트들은 소위 말하는 IDE(Integrated Development Environment)를 사용하여 개발하지는 않았다.
자바 개발자들이 이러한 IDE를 사용하지 않는 이유가 뭘까? 필자의 경우는 자바를 배울 때부터 Text Editor를 이용하여 배웠고 지금까지 진행한 프로젝트에서도 단순 텍스트 에디터만 이용하였기 때문에 이러한 방식이 손에 익었기 때문이다. 또한 대부분의 자바 IDE 도구들이 자바로 개발되었기 때문에 이 IDE를 실행하거나 메뉴의 이동에 너무 느렸기 때문이다.
이유야 어떻든 현재 대부분의 개발자들은 Ultra Editor, Edit Plus 등과 같은 단순 텍스트 에디터로 대규모의 프로젝트를 진행하고 있다. 물론 필자도 이 글을 작성하기 전까지의 프로젝트만 해도 Ultra Editor로 개발을 하였었다.
여기서 소개할 eclipse는 지금까지의 IDE와는 전혀 다른 방식으로 접근하고 있으며 무료로 배포되고 있어 프로젝트에서 별도의 경비 없이 사용가능하기 때문에 앞으로 많은 개발자들이 이 eclipse를 사용하게 되지 않을까 생각한다.
eclipse는 www.eclipse.org 사이트에서 무료로 다운로드 받을 수 있다. 다운로드 받은 다음 압축을 적절한 디렉토리에 풀어두기만 하면 설치는 끝난다. 참고로 다운로드 사이트를 자세히 보면 Language Packs 라는 항목이 있는데 이 Language Pack을 다운로드 받아 eclipse가 설치된 디렉토리로 복사하면 메뉴, 도움말 등이 한글로 바뀌게 된다. 필자의 경우 한글보다는 영어메뉴에 익숙하기 때문에 한글 설치는 독자들의 취향에 따라 설치하면 되겠다.
◆ 웹 어플리케이션 개발을 위한 Container Plugin 설치
웹 어플리케이션을 개발하기 위해서는 Servlet 또는 EJB Container의 환경에 맞게 디렉토리 구조, 환경설정 파일, Container의 실행 등이 이루어져야 하는데 eclipse를 이용하여 개발을 진행할 때에는 이들 Container와 관련된 설정은 해당 plugin을 설치함으로써 간단하게 모든 환경설정을 할 수 있다.
이런 plugin을 설치한 경우 eclipse 상에서 tomcat의 기동이 가능하고 debug도 사용이 가능하게 되는 장점이 있다.
여기서는 가장 일반적인 Container인 Tomcat을 기본으로 진행해보자. Tomcat Pulgin은 다음 사이트에서 다운로드 받을 수 있다.
http://www.sysdeo.com/eclipse/tomcatPlugin.html
여기서 plugin 뿐만 아니라 patch도 제공하고 있는데 이 파일은 뒤에서 설명하기로 하자.
자신의 Tomcat 버전에 맞는 Plugin을 다운로드 받은 다음 설치는 해당 파일의 압축을 푼 다음 “com.sysdeo.eclipse.tomcat_xxx” 디렉토리를 eclipse가 설치된 디렉토리 하위의 pulgin 디렉토리로 복사한다.
다운로드 받은 파일 중 path 파일은 압축을 해제한 다음 Tomcat 설치 디렉토리의 common/classes 디렉토리로 복사한다.
이 patch 과정을 수행하지 않으면 eclipse 상에서 Tomcat 프로젝트를 생성하여 JSP를 수행하게 되면 JSP 파일을 찾지 못하여 Tomcat이 이 JSP 파일을 컴파일 할 수 없다는 에러메세지가 나타난다.
실제 patch 디렉토리에 있는 파일들을 보면 JSP 클래스 로딩에 관련된 클래스임을 알 수 있다.
JasperLoader.java 파일을 보면 로딩하는 클래스 경로를 바꾸는 부분이 있다.
// JasperDebugPatch : replace begin //String classFile = name.substring(Constants.JSP_PACKAGE_NAME.length()+1) + ".class";
|
