시소당
TDD 방식으로 코딩하면서 시간을 어떻게 쓰고 있는지 추적해보니 급격하게 시간을 잡아먹는 코드를 찾을 수 있었다. 다른
부분을 리팩토링 하고 나자 여러 개의 테스트가 실패하는데 모두 해당 코드 블럭에서 문제가 발생했다. 프로그래밍을 진척하는데
최대의 병목지점이 되는부분을 어떻게 해결할 수 있을까?
어떤 상황인지 구체적으로 설명할 수가 없으니 추상화시켜서 코드를 표현한다. 아래 코드는 테스트 대상이 되는 외부로 노출된 메소드이다.
public void doSomeBusiness() {
if(doDecision1())
doAction1();
else
doAction2();
if(doDecision2()){
doAction3();
}else
doAction4();
}
doDecision1,2와 doAction1,2,3,4가 모두 primitive라면 테스트하기가 무척 까다롭다.
Expert One-on-One J2EE Development without EJB 413쪽을 보면 다음과 같은 표현이 나온다.
desire to write testable code usually means writing good code
다른 말로 하면 얼마나 테스트하기에 용이한가 하는 점이 결국 코드의 품질을 좌우한다는 표현이다. 그런 점에서 위와 같은 코드는 품질이 낮은 것으로 볼 수 있다.
위 코드가 만들어내는 문제점 중에서 가장 두드러진 것은 테스트 실패를 유발하는 문장이 doAction3() 이지만, 실제로 잘못된 로직이 들어간 곳은 doDecision2라는 점이다. 또한, doDecision2를 들여다 보니 한눈에 봐도 오류가 발생할 가능성이 농후한 코드이다.
private boolean doDecision2() {
if(condition1)
return condition2 || condition3;
else
return (condition4 && condition5) && condition6) || condition7;
}
테스트가 용이하게 하기 위한 방법으로 클래스를 새로 만들어 doDecision2의 로직을 위임하는 방법이 있다.
private boolean doDecision2() {
collaborator.doDecision();
}
doDecision을 public이나 package(default)로 노출하게 되어 테스트가 용이해진다.
@Test public void doDecision(){
// assertion code
}
public boolean doDecision(){
if(condition1)
return condition2 || condition3;
else
return (condition4 && condition5) && condition6) || condition7;
}
이렇게 위임을 해놓고 테스트를 만족시키려고 코드를 작성하다 보면 최초의 코드에서 doSomeBusiness 메소드의 상단 부분의 코드 역시 새로운 클래스에 위임해야 처리가 가능해짐을 알 수 있다.
if(doDecision1())
doAction1();
else
doAction2();
어떤 패턴이나 기법을 적용하지 않고 매우 자연스럽게
위임이 이루어지는 것을 경험할 수 있다. 코딩보다는 설계를 우선시하는 과잉 설계 습관을 가진 나에게는 신기할 따름이다. 아직 단정적으로 말하기는 이르지만,
대체로 기능 추가의 폭 혹은 프로그램 진화의 폭을 작게 잡고 자주 리팩토링을 할 수록 훨씬 시간이 적게 소모되는 것을 확인할 수 있다.
Test Driven Development: By Example 첫장에 소개된 내용처럼 우아하고 더디게 하는 것보다는
모양새가 좋지 않더라도(ugly) 자주 진화하는 것이 훨씬 생산적이다.
참고:
-
Expert One-on-One J2EE Development without EJB 413쪽
-
Test Driven Development: By Example 2쪽
출처 : http://younghoe.info/459