조대협의 블로그

단위 테스트 방법중에서. 특히나 J2EE의 경우에는 컨테이너를 필요로 한다. 컨테이너가 없다면 EJB나 JSP등은 구동조차 하지 않을테니까는. 이를 위한 테스트 방법이 2가지가 있는데, ○ Mock test ○ In-container test 두가지이다. Mock Test는 Container를 시뮬레이션 하는 테스트이고, In container test는 실제 컨테이너에서 테스트 하는 방법으로 JUnit을 확장한 Catcus라는 테스트 프레임웍을 사용하면된다. Apache에서 제공하는 Catcus 테스트는 크게, Servlet,JSP,Filter,Tag Lib, Struts등의 테스트가 가능하고, 자세한 정보는 http://www.apache-korea.org/cactus/writing/howto_jsp..

여러 분류가 있겠지만 ○ 단위 테스트 (Unit Test) 단위 컴포넌트의 기능이 잘 수행되는지만 체크한다. 프로그래머가 기대한데로, 단위 컴포넌트가 제대로 작동하는지만 체크할 뿐, 그것이 성능이나 장애에 대한 대처 능력이 있는지 또는 고객의 요구 사항에 부합하는지와는 상관 없이 컴포넌트 자체만 테스트한다. ○ 통합 테스트 (Integration Test) ○ 수락 테스트 (Acceptance Test) 고객의 요구 사항에 부합하는지에 대한 테스트를 수행한다. 기능 테스트는 당연하고, 성능 테스트 (Performance Test), 장애 테스트 (Failure Test) 등을 수행하게 된다.

하나의 소스를 가지고 개발 환경, 테스트 환경, QA환경, 운영 환경에 DEPLOY할때, 이를 자동화 할 필요성이 있다. ANT에 PROPERTY파일을 가지고 진행이 가능한데. http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Deploy/ManyDeploymentEnvironments.rdoc 설명이 나와있다.

JUnit의 확장판으로 데이타베이스에 대한 테스트를 자동화할 수 있게 해준다. 대부분의 Web App가 RDBMS인것을 가만한다면, 꼭 필요하지 않을까? == http://dbunit.sourceforge.net/ ==

SVN에서 자동으로 Checkout해서 Build하는 과정까지 자동화 == == 이 스크립트는 Cruise Control의 LOCAL환경에 설정을하고 실제 build.xml은 SVN안의 프로젝트(컴포넌트)안에 위치 시켜서 Build 스크립트까지 다운 로드 받도록 한다.

== build.xml == http://blog.taragana.com/index.php/archive/how-to-integrate-subversion-version-control-software-with-apache-ant/ SVNANT 라이브러리 받은후 $ANTHOME/lib에 jar파일 복사후 taskdef를 와 같이 지정하면됨.

Sep.07 Write article of “Programming know-how by 12 java programming Master” in Microsoftware magazine. July.07 Write article of “ESB to governance,technical guide for successful SOA” in Microsoftware magazine. Mar.07 Write article of “What is SOA?How to SOA?” in Microsoftware magazine Dec.06 Write article of “SOA implementation strategy with BEA product” In Eweeks magazine Nov.06 Write article ..

몬가를 시작하면 장비병이 도지는것은 어쩔 수 없나보다. 골프 클럽은 연말에나 구입할 생각이지만.. 그전에 클럽을 얻어 쓰거나 중고 클럽을 사용하는 것을 진지하게 고민중이다. 워낙 고가이다 보니 몸에 안맞는것 샀다가 고생할 수 도 있고.. 클럽을 피팅한다는 이야기도 들었기에 심사 숙고해야할듯 유력선상에 올라있는것이 미즈노 MX-25나 JPX인데... 기회있을때 시타라도 한번(시타 할 솜씨나 되나?)해봐야 겠다.

오늘 인턴 사원 평가를 했다. 예전 팀장 시절에는 체계가 없어서 제대로된 평가를 한적이 없었는데. 오늘은 인턴사원이지만 평가를 하면서 시니어로써의 무게를 느껴봤다. 하나 얻은 교훈은 "피드백을 할때, 좋은 것을 80%, 나쁜것을 20%" 이야기 하라는 것이다. 맞는말인지, 의미는 잘 모르겠지만, 예전에 내가 평가를 받을때의 느낌을 생각해보면 맞는 말 같다. 사실 피드백에서 나쁜점들이 50%이상 나온다면, 이미 그 사람은 회사에서 존재하기 어려운 사람이 아닐까? '칭찬은 고래도 춤추게 한다'고, 업적을 찬양해서 일할 수 있는 동기를 부여하고, 부족한점은 메꿔 나가게 하는것이 메니져로써의 역할이 아닐까?

한국 소프트웨어 진흥원 부탁으로 써줬던 기고인데, EAI의 도입 전략에 대해서 설명했던 글이다. == Introduction strategy of EAI 2006년 7월 5일 자바스터디 네트워크 (http://www.javastudy.co.kr) 조대협 (bcho@bea.com) 1. 왜 EAI 가 필요한가? 전통적으로 기업의 애플리케이션들의 개발은 각 부서의 업무나 특정 업무의 요구 사항에 맞춰서 필요한 시기에 전사적인 기업 업무나 기존의 IT 시스템에 대한 고려 없이 독립적으로 개발되었다. 즉, 고객 관리를 위해서 CRM이 개발이 되었고, 경영자의 데이터 분석을 위해서 DW 시스템이 개발이 되었고, 기업 내부의 전산화를 위해 그룹 웨어가 개발이 되었다. 이런 각각의 애플리케이션의 개발은 개발 당시의 ..