지난 10일(토)에 JCO에서 주관하는 2010 한국 자바 개발자 페스티벌이 이화여대 ECC에서 개최되어서 갔다가 왔습니다.
운영의 아쉬움
JCO의 컨퍼런스는 작년 10회 컨퍼런스 [해당 포스팅은 옮겨오지 않았다.. 이유는 잘 모르겠넹;;] 때 처음 참가해 보았다가 올해는 언제하나 많이 기다려던 행사였지만 좀 짚고 넘어갈 건 짚고 넘어가야되겠습니다. 사실 저는 컨퍼런스나 세미나는 주목적이 세션을 들으러가는 것이기 때문에 괜히 거창하게 하는 행사에는 그다지 관심은 없는 편입니다. 하지만 이번 JCO의 행사는 운영이 좋다 나쁘다 말하기를 떠나서 운영자체가 없는 느낌이었습니다. ㅡㅡ;;
멋진 ECC에 도착해서 "오~ 좋다~"는 감탄을 했지만 어디서도 자바 개발자 페스티벌이 개최된다는 포스터등은 볼 수가 없었고 다같이 ECC를 미로처럼 돌아다닌 끝에 겨우 A4지에 "Track 2"라고 적혀져있는 것을 찾아냈습니다. 겨우겨우 물어서 제가 신청한 Track 4를 찾을 수 있었습니다. 각 세션이 이뤄지는 장소 앞에 책상만 하나 있었을 뿐 JCO 행사라는 표시는 전혀 붙어있지 않았고 특히 ECC라는 건물이 대칭적으로 내부는 다 비슷비슷하게 생겨서 처음가보는 사람은 원하는 장소를 찾기가 어려웠음에도 행사장에 대한 표시같은 것은 전혀 없었습니다. 저는 아는 사람들도 꽤 있어서 물어물어 트랙을 찾아다녔지만 혼자서 처음 오신 분들은 꽤 고생을 하셨지 않을까 합니다.(저만 헤메인건 아니겠죠? ㅡㅡ;;) 그럴만한 장소도 아니었지만 당연히 있을꺼라고 생각했던 출판사나 업체들의 부스도 없더군요.(이건 꼭 있어야 하는 것은 아니지만 없으니 행사자체가 너무 조용한 느낌이 있었습니다.)
멋지게 생겼던 이대 ECC
사전에 등록을 할때 트랙을 선택을 하기는 했지만 비공식적으로 그냥 수요도파악정도라는 얘기를 들었길래 이전에 참가해봤던 다른 컨퍼런스와 마찬가지로 당연시 시간별로 트랙을 옮겨다닐 생각을 하고 있었지만 막상 도착을 하니 각 트랙이 장소가 꽤나 떨어져 있었고 공식적으로는 트랙간의 이동을 허용하지 않는다는 얘기를 들었습니다. (운영상의 이슈인지는 모르겠지만 별도의 관리조차도 없는 상황에서 이건 상당히 무리한 요구라고 생각되었습니다. 어떻게 관심사가 한 트랙에 다 집중될수가 있을런지요.)
가서 분위기를 파악해 보니 전체 트랙을 다 맡지는 않더라도 각 트랙을 주도하는 커뮤니티들이 있었습니다.(제가 참가한 Track 4는 KSUG의 주도하고 있었습니다.) 트랙별 신청명단과 장소만 커뮤니티에 제공되고 해당 커뮤니티에서 알아서 운영하는 분위기였는데 명단에 이름만 있고 소속도 써있지 않은 관계로 동명이인의 경우 등록에 어려움도 있었고 등록한지 몇주 되었기 때문에 자신이 어느 트랙으로 신청했는지 정확히 기억해내지 못하는 사람들은 자신의 이름을 찾아 멀리떨어져있는 트랙 발표장들을 돌아다녀야 했습니다. 각 트랙은 그냥 각 커뮤니티가 운영을 하는 분위기였기 때문에 미처 알지못하고 커뮤니티에서 도와줄 사람들을 모집해오지 못하신 곳은 발표자분들이 등록데스크를 직접 지키고 계시더군요.(안타까움과 그분들의 헌신에 눈물이... ㅠㅠ)
올해 제가 속해있는 봄싹이 JCO에 합류하게 된 관계로 이름만 알고 있던 작년에 비해서는 JCO에 상황을 약간이나마 알고 있기는 했지만 JCO는 외부에 거의 드러나지 않는 조직(제가 느끼기에)인데다가 그래도 Java에서 JCO라는 이름의 위치가 있기에 기대하고 오신 분들에게 생각치 못했던 이런 운영은 좀 실망스럽지 않았을까 생각합니다.(시간표에는 폐회도 있었는데 그냥 4세션끝나면 그냥 집에가는거더군요.) 물론 이번 페스티벌을 위해서 TFT가 조직 된 것으로 알고 있고 다들 본업이 있으신 가운에 이런 규모의 행사를 준비하는 것이 보통일은 아닐 거라고 생각하고 있지만 이번 행사의 운영에 대한 부분은 여러가지로 아쉬움이 많이 남았습니다.
테스트가능한 소프트웨어 설계와 TDD작성패턴 - 채수원
Track 4의 1세션이면서 얼마전에 TDD 책을 출간하신 채수원님의 세션이었습니다. 책을 출간하신지 얼마 안되었기 때문에 발표는 TDD책에 포함된 내용의 프리뷰 혹은 축약적인 형태의 발표였고 전 얼마전에 책을 읽고 참가를 했기 때문에 복습하는 기분으로 가볍게 들었습니다.(책을 쓰면서 세션발표를 위해서 비기를 숨겨두진 않았을때니 이런 책의 축약형태의 발표는 당연한 부분이라고 생각하고 있습니다.)
 |  |  |
토요일날 이렇게 세션을 듣기 위해서 이자리에 나와있는 이유는 "보다 더 나은 소프트웨어와 보다 더 나은 삶을 만들기 위해서..."입니다. 일반적으로 개발을 하면 먼저 언어를 공부하고 프레임워크를 공부한 뒤에는 컴퓨터 공학을 공부하면서 객체지향 원칙이나 디자인 패턴등을 공부하게 됩니다. 더 나은 소프트웨어를 만들기 위해서 이지만 이런 것들을 공부해도 잘 되지 않습니다. 간단한 예제 소스를 보고 의존성이 더 많이 들어있는지에 대한 여부는 파악하기 쉽지만 어렵고 복잡한 소스들에서는 쉽게 파악하기 어렵고 경력이 쌓여도 어디가 문제라도 바로 짚어내기 어렵습니다. 이런 것은 이론으로만 공부를 해서입니다.
이 간극을 가장 쉽게 해결할 수 있는 것이 경험상으로 TDD입니다. TDD는 TDD를 하는 것 자체가 목적이 아니라 더 나은 디자인을 하기 위해서 이며 TDD를 하면 쉽게 어디가 문제라는 것을 찾을 수 있게 됩니다.
안좋은 디자인의 징후
- 단위 테스트 케이스 작성이 어렵다.
- 단위 테스트 케이스가 자주 깨진다.
- 단위 테스트 케이스 실행을 위해 준비해야 할 것이 많다.
- 다른 사람의 테스트 케이스를 읽기가 어렵다.(코드를 읽기 어려운 것이 자신의 실력이 떨어져서인 경우는 많지 않습니다.)
프로그래밍 언어는 계속 발전을 하는데 이것은 인간을 위해서입니다.
기초 점검
- 프로그램을 작성하기 전에 테스트를 먼저 하라 (Test the program before you write it.)
- 잘 동작하는 깔끔한 코드 (Clean code that works) : TDD의 목표를 자동화된 테스트를 만드는 것으로 하는 경우도 많은데 TDD의 목표는 잘 동작하는 깔끔한 코드를 만드는 것입니다.
- 질문 -> 응답 -> 정제 -> 반복 (Ask -> Respond -> Refine -> Repeat)
기본 코스
생성자 메소드 테스트 (Constructor Method Test)
처음 TDD를 할 때 여러가지 걸리는 부분들이 있는데 생성자가 가장 먼저 걸리는 부분 중 하나입니다. 꼭 정답이 있는 것은 아니지만 일반적으로 생성자 테스트는 포함시키지 않고 생성자에 비즈니스 로직이 들어가 있을 경우에만 테스트를 합니다.
동치 비교
TDD는 자신이 원하는대로 동작을 하는가에 대한 테스트인데 인스턴스에 대해서 assertEquals로 비교할 경우 레퍼런스이기 때문에 일반적으로 실패를 하게 됩니다.
이에 대한 해결책은 아래의 방법들이 있습니다.
- 내부 상태를 꺼내와서 각각 비교
- toString을 오버라이드해서 비교(약간의 꼼수같은 느낌이 있습니다.)
- 객체에 equlas메서드를 구현(하지만 이것은 제대로 만들기가 어렵습니다. Effective Java에 보면 여러장에 걸쳐서 자세하게 설명하고 있을 정도지만 의도상은 이렇게 비교하는 것이 가장 적합합니다.)
- Unitils의 assertReflectionEquals를 이용
- JUnit 4의 assertArrayEquals를 이용
- Unitils의 assertReflectionEquals나 assertLenientEquals를 이용
- List로 변환해서 비교
- TDD와 UnitTest는 다르다. : UnitTest는 자동화에 대한 부분이고 TDD는 개발방법론입니다.(그렇다고 다른 사람이 같은 의미로 사용한다고 지적질(?)하는 것은 한번쯤 생각해 보고 하기를 권하셨습니다. ㅎ)
- (Do) All or Nothing : TDD를 하기로 하면 모든 것을 다 TDD로 하려고 하는데 그러지 않는 것이 좋습니다. 다 적용하지 말고 로직이 복잡하거나 만들기 어려운 것 위주로만 해도 충분합니다.
테스트 케이스마다 메서드 하나씩 만드는 것을 권장합니다. 스켈레톤은 테스트가 깨지지 않을 정도의 껍데기 클래스를 만드는 것으로 나쁜 방법은 아니지만 숙련자가 아니면 권하지 않는 방법이고 숙련자라고 하여도 간단한 부분에만 쓰는 것이 좋습니다.
One method one assert : 이렇게 만드는 것이 좋지만 실제로 하기는 약간 어렵습니다.
Anti-pattern
테스트를 만들 때 테스트 메서드 하나가 그 안에서 완결되고 시나리오가 되는 것이 좋습니다. setUp의 픽스쳐를 이용할 수도 있지만 문맥을 이해하기 어려우면 각 테스트안에 초기화부분이 포함되는 것이 좋을 수도 있습니다.
상태기반 vs 행위기반
결과값을 비교하는 것이 상대기반의 테스트이고 간단하게 읽히고 가장 많이 쓰이는 방법입니다. 행위기반은 결과값이 아닌 특정메서드가 호출되었는가를 확인하는 방법입니다.
항상 생각만 하고 있던 TDD인데 최근에 자극도 많이 되었고 개발에 적용할때 도움이 될 책도 나왔기에 올해는 좀 적극적으로 적용을 하고 수련을 해봐야겠습니다.(말로만 끝나지 않아야 할텐데요. ㅎ) 그동안 막연히만 알고 있고 좀 잘못알고 있던 내용들도 있는데 최근에 많이 정리가 되어서 좋군요.
댓글 없음:
댓글 쓰기