인터페이스 기반으로 만들면 테스트가 쉽다. 하지만, 모든 프로그램을 인터페이스로 만드는 것은 올바르지 않을 뿐더러, 거의 가능하지도 않다.

상속을 이용한 구현상속이나 자주 쓰는 템플릿 메소드 패턴을 적용할 때 알고리즘이 정의되어 있는 부모 클래스를 테스트하기는 쉽지 않다. 더군다나, 어쩔 수 없는 로직의 복잡함으로 hook메소드를 만든 경우는 테스트를 어떻게 할지 감이 오지 않는다.

단순하게 오버라이딩된 메소드들의 로그를 찍어보고 호출되는 로그 stack을 보면서 확인을 할 수는 있으나, 알다시피 로그로 찍어서 보는 방법은 여러가지 한계가 있다.(자동화 및 대량의 테스트 등등에서 제한이 있다).

그래서 테스트를 실행시에 junit이 알아서 다 평가를 해줘서 녹색/빨간색을 던져는 것이 가장 좋다.

알고리즘이 정의된 추상클래스를 테스트를 한다면, 상속받아서 사용하는 자식 클래스들은 마음 편하게 API를 이용할 수 있을 것이다.

다음과 같은 추상클래스가 있다.

public abstract class RemoteResult {
  private String result;
  abstract boolean isSync();
  public String getResult() {
    return result;
  }
   protected void callback() throws Exception {
    // callback impl
   }
 }



다음과 같이 테스트를 만들면 된다.

public class AbstractTemplateTest extends TestCase {

 RemoteResult remoteResult = null;
 
 protected void setUp() throws Exception {
  super.setUp();  
  remoteResult = new RemoteResult(){
   public boolean isSync() {
    return true;
   }
  };
}

그 다음 구현이 되어 있는 메소들들 테스트하면 된다. 테스트하고자 하는 중요한 포인트가 템플릿 메소드의 행위라고 한다면, 좀더 아이디어를 생각해야 한다. 테스트를 만들 때는 무엇을 테스트할 것인지 생각을 하고 테스트를 하기 쉽게 디자인을 변경하는 작업도 필요하다.

조금만 정성들여서 바라봐도 테스트하기 쉬운 코드를 만들수 있을 것이다. 다음과 같은 책이 많은 도움을 준다.

Working Effectively With Legacy Code

Michael Feathers / Prentice Hall



Posted by ologist

블로그 이미지
ologist

공지사항

Yesterday221
Today25
Total34,406

달력

 « |  » 2012.02
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29      

최근에 받은 트랙백

글 보관함