Home // Blog
Home // Notice
Home // Tag Log
Home // Location Log
Home // Media Log
Home // GuestBook
[회고] SI에서 TDD를? (2)
Posted at 2010/09/01 09:19 //
in Project Life //
by
그동안 SI 프로젝트에서 웹애플리케이션에 관련된 일을 할 때, 그들과 같이 비공식적으로 TDD나 짝프로그래밍을 시도했던 적이 있다. 그리고 그것과 관련되서 구축해 줬던 라이브러리도 좀 된다. 그 중 몇가지 추려서 설명하고자 한다.
그림1은 일반적인 웹MVC의 아키텍쳐중 일부이다. 위에서 빨간색 점으로 표현한 지점이 TDD작성 포인트이다. 사실 위의 TDD작성 포인트가 MVC 웹-영역에서 사용할 수 있는 TDD의 전부라고 해도 과언이 아니다. 그에 맞는 라이브러리는 알려진게 워낙 많아서 번외로 하고 실제 프로젝트에서 직접 구성했었던 TDD작성 사례를 설명할까 한다.
"테스트데이터셋, Mock 객체, 테스트 Dao..테스트 서블릿등등등"
LG에서 시도했던 TDD의 실제 사례이다.
데이터베이스 테이블의 설계가 충분히 고려되지 못한 채 수시로 변경이 되었고 며칠 뒤로 고객에게 시연을 해야만 했다.( 또 어디서 나타났는지 우리의 관리자는 자신의 직원들은 안 쪼고 프리랜서만 닦달하고 있었다.) 고객이 원하는 UI(유저인터페이스)는 fix가 되어 있었다는 게 다행이었다. 뒷단은 수시로 변경되고 있었던 반면, 앞단은 고정되어 있었던 것이다. 여기서 선택할 수 있는 것이 가상의 Dao를 작성해서 가상의 데이터를 원하는 UI에 뿌려주는 것이다. 설계가 미진한 불안정한 데이터셋도 가상의 데이터셋을 만들어서 축출하면 그만이었다.
이때 사용했던 가상의 데이터셋은 DBUnit에서 쓰는 기본포멧이 아닌 엑셀파일이다. 굳이 엑셀파일을 선택한 이유는, DBMS가 오라클이었고 오라클에서 제공하는 엑셀 익스포터를 사용하면 빠르게 해당 포멧으로 엑셀을 생성할 수 있었기 때문이다. 이렇게 생성한 데이터셋과 가상의 Mock Object를 사용하여 테스트케이스를 완료할 수 있었고, IDao를 구현한 Real Dao를 잠시 뒤로 놓고, 새롭게 작성한 TestDao를 메모리에 올려두었다. 이렇게 해서 고객이 원하는 뷰를 빠르게 작성할 수 있게 되었다. 이 당시는 뒷단의 디비설계가 수시로 변경이 되었었는데 가상의 DataSet을 사용하려 했던 아이디어가 크게 빛을 발휘했던 것이다. 결국, 나중에 디비 설계가 완료되면 그때 TestDao에서 RealDao로 교체만 하면 그만이다.
만약 데이터셋을 갖출 때 아래 그림과 같이 수많은 테이블에서 조인된 결과물이라면 토드와 같은 툴을 사용해서 쿼리를 수행한 뒤 얻은 결과로 엑셀파일을 생성하면 된다.
위와 같은 방법을 사용해야하는 시기와 장점에 대해서 정리해 본다.
"직접 고안해낸 UI의 테스트 방법론"
그림3은 직접 삼성에서 프레임웍으로 구축해줬던 실제사례 일부분을 발췌한 것이다. ibatis를 사용하고 있었는데 뷰는 그리드컴퍼넌트를 사용하고 있어서 테스트 하기에 무척이나 까다로웠다. 이때 생각한 것 중에 하나가 UI단의 그리드 컬럼과 쿼리단에 각 컬럼명을 매핑시켜주면 그리드 테스트케이스는 작성할 수 있지 않을까하는 아이디어였다.
기존에는 컬럼 네이밍 규칙도 없었고 개발자들 제각각 컬럼명을 생성했기 때문에 통일성없는 흐름을 관찰했다. 통일성이 없으면 의존성이 증가되어 당연히 테스트도 어렵게 된다.
이렇게 쿼리단의 컬럼명과 그리고 혹은 UI단의 해더부분을 매핑시켜주면 UI의 TDD는 완료할 수 있다.
"분산처리 환경에서의 CRUD TDD"
필자는 오픈소스이외에 블랙박스 소프트웨어를 경험했었기 때문에 오픈소스로 알려져 있던, TDD관련 라이브러리들을 블랙박스와 접목해서 사용한적이 많다. 물론 해당 블랙박스 패키지속에 제공해주는 TDD관련 라이브러리들이 많이 있었지만 다루기 까다로울 때는 직접 라이브러리를 등록해서 블랙박스+오픈소스환경을 융화시키야만했다. 보통 데이터베이스를 테스트하는 용도로 CRUD의 반복되는 코드를 테스트하곤 했는데, 이때는 집적 데이터베이스와 붙지 않고 분산환경에서 가상의 프록시를 만들어 테스트를 진행해야했다.
이렇게 분산환경속에서 그것들 모두를 한곳의 테스트로 집중하기엔 의존성이라는 문제가 따라붙었다. 따라서 의존성을 제거하기위해 머신마다 단일책임원칙을 따르는 코드를 작성해야했으며 따라서 개별의 단위테스트를 진행할 수 있었다.
그림1은 일반적인 웹MVC의 아키텍쳐중 일부이다. 위에서 빨간색 점으로 표현한 지점이 TDD작성 포인트이다. 사실 위의 TDD작성 포인트가 MVC 웹-영역에서 사용할 수 있는 TDD의 전부라고 해도 과언이 아니다. 그에 맞는 라이브러리는 알려진게 워낙 많아서 번외로 하고 실제 프로젝트에서 직접 구성했었던 TDD작성 사례를 설명할까 한다.
"테스트데이터셋, Mock 객체, 테스트 Dao..테스트 서블릿등등등"
LG에서 시도했던 TDD의 실제 사례이다.
데이터베이스 테이블의 설계가 충분히 고려되지 못한 채 수시로 변경이 되었고 며칠 뒤로 고객에게 시연을 해야만 했다.( 또 어디서 나타났는지 우리의 관리자는 자신의 직원들은 안 쪼고 프리랜서만 닦달하고 있었다.) 고객이 원하는 UI(유저인터페이스)는 fix가 되어 있었다는 게 다행이었다. 뒷단은 수시로 변경되고 있었던 반면, 앞단은 고정되어 있었던 것이다. 여기서 선택할 수 있는 것이 가상의 Dao를 작성해서 가상의 데이터를 원하는 UI에 뿌려주는 것이다. 설계가 미진한 불안정한 데이터셋도 가상의 데이터셋을 만들어서 축출하면 그만이었다.
이때 사용했던 가상의 데이터셋은 DBUnit에서 쓰는 기본포멧이 아닌 엑셀파일이다. 굳이 엑셀파일을 선택한 이유는, DBMS가 오라클이었고 오라클에서 제공하는 엑셀 익스포터를 사용하면 빠르게 해당 포멧으로 엑셀을 생성할 수 있었기 때문이다. 이렇게 생성한 데이터셋과 가상의 Mock Object를 사용하여 테스트케이스를 완료할 수 있었고, IDao를 구현한 Real Dao를 잠시 뒤로 놓고, 새롭게 작성한 TestDao를 메모리에 올려두었다. 이렇게 해서 고객이 원하는 뷰를 빠르게 작성할 수 있게 되었다. 이 당시는 뒷단의 디비설계가 수시로 변경이 되었었는데 가상의 DataSet을 사용하려 했던 아이디어가 크게 빛을 발휘했던 것이다. 결국, 나중에 디비 설계가 완료되면 그때 TestDao에서 RealDao로 교체만 하면 그만이다.
만약 데이터셋을 갖출 때 아래 그림과 같이 수많은 테이블에서 조인된 결과물이라면 토드와 같은 툴을 사용해서 쿼리를 수행한 뒤 얻은 결과로 엑셀파일을 생성하면 된다.
위와 같은 방법을 사용해야하는 시기와 장점에 대해서 정리해 본다.
1. 앞단의 개발자(UI개발자)와 뒷단의 개발자(서버개발자)가 분리되어 있을 경우, 간섭현상을 줄일 수 있다.
2. 데이터베이스 설계가 미진하지만 UI는 고정된 상태에서 제법 유용한게 쓸 수 있다. (Mock Object)
3. 테스트데이터를 쉽게 구비하지 못할 때 엑셀과 같은 가상의 데이터셋을 사용하면 알맞은 테스트데이터를 마련할 수 있다.
4. 모두 TDD에 용이하다.
2. 데이터베이스 설계가 미진하지만 UI는 고정된 상태에서 제법 유용한게 쓸 수 있다. (Mock Object)
3. 테스트데이터를 쉽게 구비하지 못할 때 엑셀과 같은 가상의 데이터셋을 사용하면 알맞은 테스트데이터를 마련할 수 있다.
4. 모두 TDD에 용이하다.
"직접 고안해낸 UI의 테스트 방법론"
그림3은 직접 삼성에서 프레임웍으로 구축해줬던 실제사례 일부분을 발췌한 것이다. ibatis를 사용하고 있었는데 뷰는 그리드컴퍼넌트를 사용하고 있어서 테스트 하기에 무척이나 까다로웠다. 이때 생각한 것 중에 하나가 UI단의 그리드 컬럼과 쿼리단에 각 컬럼명을 매핑시켜주면 그리드 테스트케이스는 작성할 수 있지 않을까하는 아이디어였다.
기존에는 컬럼 네이밍 규칙도 없었고 개발자들 제각각 컬럼명을 생성했기 때문에 통일성없는 흐름을 관찰했다. 통일성이 없으면 의존성이 증가되어 당연히 테스트도 어렵게 된다.
이렇게 쿼리단의 컬럼명과 그리고 혹은 UI단의 해더부분을 매핑시켜주면 UI의 TDD는 완료할 수 있다.
"분산처리 환경에서의 CRUD TDD"
그림4. 분산처리 환경에서의 CRUD 테스트
필자는 오픈소스이외에 블랙박스 소프트웨어를 경험했었기 때문에 오픈소스로 알려져 있던, TDD관련 라이브러리들을 블랙박스와 접목해서 사용한적이 많다. 물론 해당 블랙박스 패키지속에 제공해주는 TDD관련 라이브러리들이 많이 있었지만 다루기 까다로울 때는 직접 라이브러리를 등록해서 블랙박스+오픈소스환경을 융화시키야만했다. 보통 데이터베이스를 테스트하는 용도로 CRUD의 반복되는 코드를 테스트하곤 했는데, 이때는 집적 데이터베이스와 붙지 않고 분산환경에서 가상의 프록시를 만들어 테스트를 진행해야했다.
이렇게 분산환경속에서 그것들 모두를 한곳의 테스트로 집중하기엔 의존성이라는 문제가 따라붙었다. 따라서 의존성을 제거하기위해 머신마다 단일책임원칙을 따르는 코드를 작성해야했으며 따라서 개별의 단위테스트를 진행할 수 있었다.
본인은 TDD와 관련된 라이브러리에대해 지식이 없었을 땐, 직접 테스트케이스를 위한 별도의 라이브러리를 구축해서 테스트를 진행하기도 했다. 정 여력이 없을 땐 main 메소드에 테스트를 했다.
얼마전에 나온 "테스트주도개발 TDD실천법과 도구" 를 통해서 본인이 생각하고 구축해 주었던 부분이 상당수 책에 실려었었던 것을 확인했다. 물론 본인도 TDD는 해외사이트나 기사를 통해서 학습을 했었고 unitils와 같은 라이브러리는 그동안 수차례 공부를 해왔던 경험이 있기 때문에 본인이 아는 내용과 책 내용이 상당수 중복되는 부분이 많았다.
그리고 위의 컬럼명 매핑에대한 부분은 순전히 개인적인 생각으로 삼성에 제공한 라이브러리였는데, 그것과 비슷한 방법이 이 책에 실려있어 깜짝 놀랐다.! 세상엔 참으로 비슷한 생각을 하고 실천하는 사람이 많다는 것을 새삼 깨닫게 해주었다. ( 실제 프로젝트에서 만나볼 수 없었던 비슷한 가치를 지닌분들 ).
얼마전에 나온 "테스트주도개발 TDD실천법과 도구" 를 통해서 본인이 생각하고 구축해 주었던 부분이 상당수 책에 실려었었던 것을 확인했다. 물론 본인도 TDD는 해외사이트나 기사를 통해서 학습을 했었고 unitils와 같은 라이브러리는 그동안 수차례 공부를 해왔던 경험이 있기 때문에 본인이 아는 내용과 책 내용이 상당수 중복되는 부분이 많았다.
그리고 위의 컬럼명 매핑에대한 부분은 순전히 개인적인 생각으로 삼성에 제공한 라이브러리였는데, 그것과 비슷한 방법이 이 책에 실려있어 깜짝 놀랐다.! 세상엔 참으로 비슷한 생각을 하고 실천하는 사람이 많다는 것을 새삼 깨닫게 해주었다. ( 실제 프로젝트에서 만나볼 수 없었던 비슷한 가치를 지닌분들 ).
'Project Life' 카테고리의 다른 글
| 인터넷 비방건에 대해. (3) | 2010/09/09 |
|---|---|
| [공과 사] 폭언과 폭행의 단계. (0) | 2010/09/07 |
| [회고] SI에서 TDD를? (2) (5) | 2010/09/01 |
| [회고] SI에서 TDD를 - 번외적인 모습들 (1) (3) | 2010/09/01 |
| 소프트웨어 관리자가 봐야할 필독서와 URL (6) | 2010/08/21 |
| 어설픈 관리와 갑이 되고 싶은 마음. (1) | 2010/08/20 |
사람 향기 나는 사람이 되기!
올해의 키워드는 '행복'입니다.
(OST..) 움직움직.;;;:) @god [찾으라 그러면 찾아낼 것이요 - 눅 11:9 ]
2010/09/01 09:49 [수정/삭제] [답글]
노..전문적인 프로의 포스가 팍팍 느껴지는군요.
인사만 드리고 갑니다~ㅎ
2010/09/03 20:19 [수정/삭제]
안녕하세요^^ 잘 지내시죵?
2010/09/01 13:55 [수정/삭제] [답글]
비밀댓글입니다
2010/09/03 09:43 [수정/삭제] [답글]
최근에 저희 회사에서 일하셨었다는걸 알고는 깜짝! 놀랬습니다. 프로젝트룸 근처에 왔다갔다 한 적 많았었거든요. :D 어려가지로 신기한것 같아요.
UI - SQL 접점에 대한 TDD는 효과는 어느정도 있긴 했었는데요, 아쉬웠던 점은 개발자들이 그다지 '재미'를 느끼지 못했다는 점이었습니다. 과정 자체가 성공의 기쁨을 느낄만큼 도전적이지 않았었던것이 원인이 아니었나 하고 스스로 회고해 봅니다.
2010/09/04 17:10 [수정/삭제]
홋 그랬었군요. 프로젝트 단위로 움직이다 보니..지나치면서 만났을 수도 있었겠군요
맞습니다. 개발자가 생각할 때 그 일을 어떻게 생각하느냐, 재미있어하느냐 재미없어하느냐가 매우 중요한 것 같습니다. 그전에 그분들에게 동기부여를 해 줘야 하는데 어려운 상황이 많은지라 그러기가 매우 힘이든 것 같습니다. 또한, 저도 그렇구요^^. 취미로 하기엔 재미있는데 실무에서 하기엔 충분한 동기부여가 매번 모자라곤 하더군요.
그래도 재미를 느끼는 열정 있는 사람들이 꾸준히 노력한다면 그 재미가 전염되지 않을까 합니다. ㅎ