◆ 켄트벡이 주장하는 TDD(서문 중에서)
번역하기가 너무 어려워 원문 그대로 올립니다.
Test-Driven Development By Example
Clean code that works, in Ron Jeffries’ pithy phrase. The goal is clean code that works, and for a whole bunch of reasons:
l Clean code that works is a predictable way to develop. You know when you are finished, without having to worry about a long bug trail.
l Clean code that works gives you a chance to learn all the lessons that the code has to teach you. If you only ever slap together the first thing you think of, you never have time to think of a second, better, thing.
l Clean code that works improves the lives of users of our software.
l Clean code that works lets your teammates count on you, and you on them.
l Writing clean code that works feels good.
But how do you get to clean code that works? Many forces drive you away from clean code, and even code that works. Without taking too much counsel of our fears, here’s what we do—drive development with automated tests, a style of development called “Test-Driven Development” (TDD for short). In Test-Driven Development, you:
l Write new code only if you first have a failing automated test.
l Eliminate duplication.
Two simple rules, but they generate complex individual and group behavior. Some
of the technical implications are:
l You must design organically, with running code providing feedback between decisions
l You must write your own tests, since you can’t wait twenty times a day for someone else to write a test
l Your development environment must provide rapid response to small changes
l Your designs must consist of many highly cohesive, loosely coupled components, just to make testing easy
The two rules imply an order to the tasks of programming:
1. Red—write a little test that doesn’t work, perhaps doesn’t even compile at first
2. Green—make the test work quickly, committing whatever sins necessary in the process
3. Refactor—eliminate all the duplication created in just getting the test to work
Red/green/refactor. The TDDs mantra.
Assuming for the moment that such a style is possible, it might be possible to dramatically reduce the defect density of code and make the subject of work crystal clear to all involved. If so, writing only code demanded by failing tests also has social implications:
l If the defect density can be reduced enough, QA can shift from reactive to proactive work
l If the number of nasty surprises can be reduced enough, project managers can estimate accurately enough to involve real customers in daily development
l If the topics of technical conversations can be made clear enough, programmers can work in minute-by-minute collaboration instead of daily or weekly collaboration
l Again, if the defect density can be reduced enough, we can have shippable software with new functionality every day, leading to new business relationships with customers
So, the concept is simple, but what’s my motivation? Why would a programmer take on the additional work of writing automated tests? Why would a programmer work in tiny little steps when their mind is capable of great soaring swoops of design? Courage.
◆ 필자의 의문사항
☞ 테스트 파일 단위
☞ 테스트 데이터의 생성
☞ 웹 레이어와 비즈니스 레이어 테스트 사이에 발생하는 코드의 중복
☞ 웹 계층과 비니지스 계층의 개발을 병렬로 개발할 경우의 테스트 방안
☞ cactus를 이용하는 경우 한글 처리 문제
4. 글을 마치며.
이번 글의 목적은 eclipse가 아니라 TDD(Test-Driven Development)에 있다고 할 수 있다. TDD를 하기 위해 조금이나마 개발자들의 수고를 덜기 위해 eclipse를 사용했던 것이다. 하지만 개발자들이 얼마나 많이 이 TDD를 사용하게 될지는 필자 역시 의문이다.
TDD를 설명 받은 대부분의 개발자들이 모두 비현실적이고 이상적인 이론이라는 것이다. 필자 역시 처음에는 그러한 생각을 가지고 시작했지만 실제 몇 개의 테스트 코드를 작성해보고 테스트를 수행하고 기존에 만든 코드에 새로운 기능을 추가하고 테스트를 수행하는 절차를 거치면서 테스트 프로그램의 막강한 위력에 실감을 하였다.
물론 개발 납기에도 맞추기 어려운 상황에서 테스트 코드까지 만들어야 한다는 부담감이 있을 수는 있다. 하지만 실제 프로젝트에서 어떻게 진행되고 있는지 한번 보자. 개발자들은 자신의 프로젝트의 일정에 맞추어 자신이 맞은 프로그램 목록 상의 기능을 개발한다. 문론 정해지니 일정이 있기 때문에 간단한 단위 테스트 정도만 수행하고 다음 프로그램으로 넘어간다. 이렇게 2 ~ 4개월 정도의 코딩이 끝난 다음 프로젝트 막바지에 전체적인 통합 테스트를 수행하게 되면 많은 예상하지 못한 프로그램 오류가 나타나게 된다. 그러면 개발자들은 이 오류를 수정하기 위해 프로그램을 수정하고 또 테스트를 하게 된다. 프로그램을 수정할 때에도 2 ~ 4개월 전에 작성한 프로그램이기 때문에 제대로 생각도 나지 않고 실제 어떻게 테스트를 해야 하는지 모를 경우도 많다. 납기는 맞추어야 하기 때문에 밤을 새워가며 간신히 통합 테스트를 통과했다 하더라도 개발자의 마음속에는 여전히 불안한 마음을 지울 수 없게 된다. 대부분이 이렇지 않은가? 이것을 해결할 수 있는 다른 방법이 있다면 최소한 한번정도는 시도해볼 수 있지 않을까 하는 것이 필자의 주장이다.
이제 국내 프로젝트도 소스 코드 자체의 품질에 관심을 가져야 한다. 언제까지 개발자들의 양심(?)에만 의존할 수는 없다. 개발자의 의지만으로는 TDD는 절대 수행 할 수 없다라는 것이 필자가 생각이다. 물론 앞서나가는 개발자라면 자신이 개발한 소스 부분에 대해서만이라도 TDD를 할 수 있겠지만 이러한 개발자 하나의 노력만으로 어렵다. 프로젝트 관리의 요소로 이 TDD를 도입하여 개발자들을 교육시키고, 테스트 기법에 대해 연구하는 노력이 필요하다 할 수 있다.
프로젝트의 가장 중요한 산출물은 설계 문서가 아닌 제대로 운영되는 소스(Clean code that work)이다.
마지막으로 이 글에서 작성한 내용은 필자의 개인적인 의견으로 작성되었으며 필자 역시 전체적으로 이해하지 못한 상태에서 파일럿 프로젝트 성격으로 진행된 사항이기 때문에 실제 프로젝트 진행시 또는 개념적으로 잘못 작성되었을 수도 있다는 것을 다시 한번 밝히면서 작성된 글 중 잘못된 부분이나 더 좋은 방안을 가지고 있는 개발자가 있으면 반드시 연락을 주시기 바랍니다. 저 역시 혼자서 학습을 진행하다 보니 너무 어려운 점이 많네요. ^^
◆ Reference
[1] 「Test-Driven Development By Example」
Kent Beck , 2002
[2] 「http://www.eclipse.org」
eclipse 홈페이지
[3] 「http://www.junit.org」
JUnit 홈페이지
[4] 「http://www7b.software.ibm.com/wsdd/partners/merant/」
PVCS에 대한 eclipse 적용 관련 페이지
[5] 「http://www.jlab.net/」
한국 eclipse 사용자 모임
[6] 「http://xper.org/wiki/xp/」
한국 eXtreme Programming 사용자 모임
[7] 「JSP Model2를 이용한 웹사이트 구축 사례」
김형준, 2003
[8] 「http://www.javajigi.net/」