본문 바로가기

카테고리 없음

개발자와 프로그래밍의 가치을 높여주는 JUnit

오늘은 정장을 입었습니다. 자유롭게 입다가 정장을 입었더니 불편합니다. 정장이란 옷 자체는 비싼 만큼 기능적으로 불편하진 않을 텐대 마음이 불편한가 봅니다.

그러나 정장을 입었더니 말과 행동이 조심스러워 지면서 나도 모르게 어른스럽게 행동하는 것 같습니다. 그리고 정장을 입으니 인물이 달라보인다(?) 라는 '이것은 칭찬한것도~ 안한것도 아녀~' 식의 덕담도 들었습니다.

정장을 입으면 마음이 불편하여 왠지 입기는 싫지만, 일단 입으면 나를 품위있게 바꿔 나의 가치를 높여주는 효과를 가지고 있습니다.


제가 좋아하는.. 사실은 좋아하려고 노력하는 JUnit가 정장과 같은 효과를 가지고 있습니다. JUnit란 단위 테스트를 도와주는 자바 테스트 프레임워크 입니다. 자세히 설명하면 우리는 보통 프로그램을 개발할 때

> 막 개발 프로그래밍
1. 일단 만들고 보자. 시작…
2. 일단 끝..실행..이것 소스가 베베 꼬이긴 했지만 돌아는 가는구나
3. ‘가가가’, ‘나나나’ 테스트 데이터 몇 개 넣어보고 뭐.. 이정도면 되겠지~!

식의 개발 흐름를 가지고 있습니다. 특히 우리나라의 빨리 빨리~ 문화에 익숙해진 우리 개발자들은 위의 흐름을 따를 것입니다.

JUnit은 개발 흐름(프로세스)이 특별합니다.이미 많은 고수 개발자들이 쓰고 계시기 때문에 잘 아시겠지만 당시 저는 왜 이렇게 짜야 하나~ 하고 한참 어리둥절 했습니다.

> JUnit 프로그래밍
1. 이 클래스에 있어야 할 ‘기능(=메소드=인터페이스)’을 생각한다.
2. '그 기능'에 임의의 테스트 값을 넣었을 때, 내가 의도한 결과값이 나오는가를 JUnit 테스트 클래스에 명시(=구현)한다.
3. 2.번의 테스트가 성공할 수 있도록 '그 기능'의 로직을 마구잡이로~ 구현한다.
4. 마구잡이로~ 구현한 '그 기능'의 로직을 깔끔하게 리팩토링~ 한다.

틀릴수도 있겠지만 JUnit 프로그래밍의 큰 흐름이 위와 같습니다. 이제 막 자바 공부하는 분들은 이해하기 어려울수도 있지만 경력 있는 자바 개발자분들은 많이 들어보셨을 것 입니다.

저는 JUnit 방식의 개발 흐름을 따를려고 노력을 했습니다. 최근에는 저만 JUnit 방식의 개발 흐름을 따르는 것이 아니고 같이 일하는 개발자까지 ‘JUnit 함께 해요~’ 하며 설득 및 개발 독려까지 해보았습니다.

이렇게 나름대로 적용해본 결과 제가 느낀 JUnit 프로그래밍~ 의 효과가 있었습니다. 그 효과를 정리하면 다음과 같습니다.

> JUnit 프로그래밍 효과
1. 프로그래밍 관점의 JUnit 사용 효과
 1.1 기능(=메소드=인터페이스)에 집중하는 효과
 1.2 Exception 처리에 집중하는 효과
 1.3 테스트 케이스 문서화의 효과
 1.4 기능은 그대로인 상태에서 내부 소스 개선(=리팩토링)시 '막 개발' 때는 절대 발견 못할 꼭꼭 숨은 버그도 잡아준다.

2. 개발자 관점의 JUnit 사용 효과
 2.1 하나하나 차근차근 구현 목표에 접근하기 때문에 마음이 들뜨지 않고 안정감이 생긴다.
 2.2 역시 위와 같은 이유로 집중하는 습관이 생긴다.
 2.3 그러나 조금만 느슨해지면 여전히 막 개발 하고 싶은 것은 왜 그럴까~

그리고 JUnit 사용하면서 제가 얻은 노하우~는 일단 떠오르는게 하나인데요. 정리하면서 몇 개 추가할 예정입니다.

> JUnit 프로그래밍 요령
1. 테스트 케이스가 DB, UI, 통신방식에 의존되지 않고 독립 실행가능하게 하라

일단 개략적인 내용을 정리해봤는데요. 얼마전에 연재글로 쓰다가 흐지부지한 객체지향 토론이란 글 기억나십니까. 이 글과 함께 JUnit에 대하여 차근차근 정리할 예정입니다. (오래 걸리더라도 말이죠. ^ ^;)

왜냐면 객체지향 글이던 JUnit 글이던 잘 정리할수만 있다면 프로그램 짜는 것 못지 않게 글쓰기로도 기술습득에 많은 도움이 되리라는 생각을 하고 있기 때문입니다.

그리고 JUnit 관련 기술이 오묘하고 심오하다고 할까요. 이런 생각이 드는게 원래는 JUnit 조금 다뤄보고 나 TDD(테스트 주도 개발) 할 줄 안다고 프로필에도 쓰고 그랬는데 관련 칼럼들을 읽어보니 이해안가는 어려운 내용들이 많이 있었습니다.

저는 독학으로 공부 하다 보니 제가 모르는 TDD 기법이 많이 있구나 라는 생각이 들어서 그냥 JUnit 편리하게 쓰고 있어요~ 라고 해야겠구나 싶었는데요. 이런 글 쓰면서 고수 개발자분들의 피드백도 받을 수 있다면 금상첨화~ 라는 생각입니다. 그리고 글쓰기를 통해 구독자와 지식 공유도 되고요~! (이번 글도 틀린글이나 첨가하실 의견 있으시면 피드백 부탁드립니다. ^ ^)


그럼 오늘은 제가 느낀 JUnit의 효과 정리 및 IBM developerWorks의 JUnit 관련 기사 소개로 마무리 하겠습니다.

JUnit 사용 효과중에
1.4 기능은 그대로인 상태에서 내부 소스 개선(=리팩토링)시 막 개발 때는 절대 발견 못할 잡기 어려운 버그도 잡아준다.
가 있다고 했는데요.

이게 무슨 말이냐면 각 클래스 해당 기능의 단위 케이스를 충실하게 구현했고 이것을 묶어서 한번에 테스트 가능하게(=Composite) 해놓았다면, 기능은 그대로인 상태에서 내부 소스 개선(=리팩토링)시 막 개발 때는 절대 발견 못할 잡기 어려운 버그도 잡아준다~ 라는 뜻 입니다.

제가 위의 경험을 이번 사내 프로젝트에서 종종 경험 해봤기 때문에 피부로 와 닿는 내용입니다. 그런데 모든 JUnit 단위케이스를 Composite로 묶어서 한방에 테스트 하는 절차를 Ant나 기타 유틸리티들로 자동화하면 더욱 더 편리하고 안전한 개발을 할 수 있을 것 입니다.

제가 소개할 IBM developerWorks의 '사람을 위한 자동화: 연속 테스팅 (한글)' 기사는 바로 방금 설명한 편리함과 안전함을 누릴 수 있는 유익한 기법을 설명하고 있습니다.

저 Ant 및 기타 유틸리티 통한 한방 JUnit 테스트는 저도 아직 안해봤는데요. 곧 해봐야겠습니다.~!

그리고 마지막으로
2.3 그러나 조금만 느슨해지면 여전히 막 개발 하고 싶은 것은 왜 그럴까.
JUnit가 써보니 좋은 것을 많이 느끼는데 왜 2.3의 습관은 여전할까 생각하다가 서두에 쓴 ‘정장’이 생각났습니다.

JUnit는 정장처럼 개발자와 프로그래밍의 품격과 가치를 높여주지만 그래도 귀차니즘을 추구하는 인간의 본성은 어쩔수 없는 것 같습니다.

귀차니즘을 이겨내고 더 공부하고 생각해봐야 겠습니다.

> IBM developerWorks