Extremely Agile/TDD2008.11.04 14:20
앞서 남이 짠 클래스 코드를 어떻게 리팩토링하면 jMock을 통해 테스트하기가 좀 더 쉬워지는지를 살펴봤습니다. 그런데 현실 세계의 클래스들이 전부 그렇게 간단하게 만들어져 있으면 문제가 쉬운데, 실제로 테스트를 진행하다보면 그렇지 않은 경우를 종종 만나게 됩니다.

가장 골치아픈 경우 중 하나는, 생성자 안에 해당 클래스의 비즈니스 로직(?)이 들어가 있는 경우죠. 그러니까 좀 돌려서 말하면, 클래스의 생성자 코드 안에 테스트해야하는 알고리즘의 일부가 들어가 있는 경우입니다. 이 알고리즘이 대상으로 하는 객체들 중 하나를 Mock 객체로 만들어 테스트해야 한다면, 상황은 간단히 풀리지 않습니다. 다음 코드를 보시죠.

class Foo {
    public Foo() {
        ...
        bar.doSomething();
        ...
    }
    ...
};

bar에게 뭔가를 하고 있습니다. 그런데 bar에 doSomething을 호출하는 순간 네트워크 접속이 발생하기 때문에, 그 상황을 피하기 위해 bar를 mock 객체로 만들고 싶다고 해 보죠. 앞선 글에서 사용한 방법(아마 패턴을 아시는 분이라면 그 방법이 소위 '템플릿 메소드 패턴'인건 아시겠습니다만...)을 그대로 써먹자면 다음과 같이 해야 할 텐데요.

class Foo {
    protected void doSomething() {
        ..
        bar.doSomething();
        ..
    }

    public Foo() {
        ...
        doSomething();
        ...
    }
    ...
}

얼핏 보면 그럴듯해 보입니다만, 다음과 같이 하는 순간 문제가 복잡해집니다.

class FooT extends Foo {

    private Bar bar;

    protected void doSomething() {
        ...
        // do something with bar
    }

    public FooT() {
        super();
        // do something with bar
    }
}

왜 문제가 복잡해지죠? FooT의 생성자가 불리는 순간, 상위 클래스의 생성자가 불리면서 doSomething()이 호출되는데, 이 때 호출되는 doSomething은 하위 클래스에 정의된 doSomething이어야 하거든요. 그런데 아직 객체가 완전히 초기화도 되지 않은 상태이니, 하위 클래스의 doSomething이 제대로 수행될 리가 없죠. 이런 문제는 C++이건 Java건 공통적으로 발생하는 문제입니다. C++에서는 가상 함수 포인터 초기화에 관련된 오류가 발생하면서 프로그램이 죽는 현상이 발생하고, Java에서는 멤버 변수 초기화에 관한 오류 메시지가 뜨면서 프로그램이 죽습니다.

이 문제는 "Don't call subclass methods from a superclass constructor"라는 글에 잘 정리가 되어 있습니다. 요지는 When designing a class for subclassing, it’s important to avoid calling any method that the subclass could or must override from the superclass constructor. 인데, 간단히 요약하면 "하위 클래스가 오버라이드할 가능성이 있는 메소드를 생성자 안에서 호출하는 것은 피해라"라는 뜻입니다. 하위 클래스에서 오버라이드를 해버리면, 이런 문제가 생길 수 있으니까요.

그러니까 생성자 안에 테스트 해야할 알고리즘의 일부가 들어있는 경우에는, 원래 클래스의 코드를 수정하는 일이 불가피해지고 맙니다. 그런 일이 자주 생기면 좋지 않기 때문에, 가급적 생성자 안에는 "초기화에 관련된 코드들"만을 두는 것이 바람직하겠습니다.

그럼 "어쩔수 없이 원래 클래스 코드를 수정해야 하는 경우"에는 어떻게 수정하는 것이 바람직 할까요? 가령 다음과 같은 클래스가 있다고 해 봅시다. 제가 실무에서 만난 클래스입니다.

public class Connection implements Definition {
   ...
   public Connection(String ip, int port, int type) throws Exception {
      ...
   }
   ...
}

이 생성자는 내부적으로 Socket 객체를 생성하여 그 메소드를 호출합니다. 골치아픈 생성자죠. ㅋㅋ 우리가 해결해야 할 목표는, Socket 객체를mock객체로 바꿔칠 수 있는 방법을 Connection 클래스에 추가하는 것이었습니다. 그래서 코드를 다음과 같이 변경했습니다.

public class Connection implements Definition {
   ...
   public Connection(String ip, int port, int type) throws Exception {
      init(ip, port, type, null);
   }
   
  Connection(String ip, int port, int type, Socket alternativeSocket) throws Exception {
      init(ip, port, type, alternativeSocket);
   }

   private void init( ... ) {
      // if alternativeSocket is not null, do something with it.
      // or, create Socket object and deal with it
   }
   ...
}

간단히 요약하면, (1) initialization 로직은 별도의 private 함수로 refactoring하고 (하위 클래스에 의해 오버라이드 되지 않아야 하기 때문에 private입니다) 그 함수의 네번째 인자로 외부에서 정의한 소켓 객체 (mock 객체겠죠)를 받은 경우 그 객체를 가지고 필요한 작업을 하도록 변경했으며, (2) 테스트를 위한 별도의 생성자를 정의하고, 그 생성자의 네번째 인자로 mock 객체를 인자로 받아 init 함수에 넘기도록 한 다음 (3) 원래 생성자는 init 함수를 호출하되 네번째 인자로 null을 넘기도록 코드를 변경했습니다.

이렇게 함으로써 코드에 그다지 '큰' 변경을 가하지 않고서도 테스트 가능성을 확보할 수 있었습니다. 새로 추가된 생성자는 그 scope가 package 이어야 합니다. 그래야 테스트 코드 안에서만 사용이 가능할테니까요.

[다음 글에서 계속...]

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Extremely Agile/TDD2008.11.03 16:09

그러면 오늘은 jMock을 이용해 남의 코드를 테스팅하는 과정을 한번 살펴보겠습니다. 정답이라고 할 수는 없고, 저 개인적인 경험에 따른 것이니, 참고 정도 하시면 좋을 것 같습니다.

남의 코드를 테스팅할 때 중점적으로 고려한 사항은 다음과 같습니다.

1. 남의 코드의 인터페이스는 손대지 않는다.
2. 남의 코드의 주 알고리즘은 손대지 않는다.


물론 2는 어쩔 수 없이 손대야 할 경우도 생기긴 합니다만, 가급적 그러지 않는 것이 정신건강상 이롭습니다. 왜 그런지는 아마 여러분들도 잘 아실 거라 생각합니다.

그러면 이제 실제 사례를 살펴보겠습니다. ConnectionManager라는 클래스입니다. 이 클래스는 대략 다음과 같은 골격을 가지고 있습니다.

public class ConnectionManager extends Thread implements Definition {
  ...
 
  ConnectionManager(PolicyAgent pa) {
  ...
  }
  ...

  public void connect() {
    Connection conn = null;
    // main algorithm
    ...
    conn = new Connection(this.policyAgent.primaryServer, this.svrPort, ...);
    ...
  }

  ...
}

이 코드를 테스트하는 데 있어서 가장 큰 문제는, 내부에서 생성하고 관리하는 Connection 객체가 어딘가로 TCP/IP 연결을 시도한다는 점이었습니다. 코드를 단위테스트하는 와중에는 해당 서버가 없었기 때문에, 우리는 Connection 객체를 어떻게든 'mock' 해야만 했습니다. 그런데 생성하는 코드가 주 알고리즘에 뒤섞여있었기 때문에 애매한 상태였죠.

그래서, 우선은 주 알고리즘에서 Connection 객체를 생성하는 코드를 별도의 메소드로 분리하고, 알고리즘 안에 포함되어 있던 new Connection 부분을 전부 createConnection을 호출하도록 변경했습니다.

public class ConnectionManager extends Thread implements Definition {
  ...
 
  ConnectionManager(PolicyAgent pa) {
  ...
  }
  ...

  protected Connection createConnection(String svr, int port, int type) {
    return new Connection(svr, port, type);
  }

  public void connect() {
    Connection conn = null;
    // main algorithm
    ...
    conn = createConnection(this.policyAgent.primaryServer, this.svrPort, ...);
    ...
  }

  ...
}

이렇게 한 다음에, JUnit 코드 안에서 ConnectionManager 클래스 코드를 계승하여 ConnectionManagerT라는 클래스를 정의했습니다.

class ConnectionManagerT extends ConnectionManager {
 private List<Connection> extConns = null;

 public ConnectionManagerT(PolicyAgent parent) {
  super(parent);
  this.extConns = new LinkedList<Connection>();
 }

 void addExternalConnection(Connection extConn) {
  synchronized( this.extConns ) {
   this.extConns.add( extConn );
  }
 }

 private Connection getExternalConnection() {
  synchronized( this.extConns ) {
   if ( this.extConns.isEmpty() ) return null;
   return this.extConns.remove(0);
  }
 }

 protected Connection createConnection(String svr, int port, int type) {
  Connection conn = null;
  if ( (conn = getExternalConnection()) == null ) {
   return super.createConnection(svr, port, type);
  }
  return conn;
 }
 ...
}

그리고 이 클래스 안에서 createConnection메소드를 오버라이드 했습니다. 이제 테스트 코드에서는 ConnectionManager 클래스를 사용하는 대신, ConnectionManagerT 클래스를 사용해서 테스트를 진행하면 됩니다. ConnectionManager 클래스에 정의된 알고리즘이 createConnection을 호출하는 순간, 하위 클래스에 정의된 createConnection이 호출될 것이고, 이 메소드는 new Connection을 하는 대신 getExternalConnection 메소드를 호출하여 connection을 얻을 것이기 때문에, mock 객체를 통해 주 알고리즘의 테스트가 진행되도록 만들 수 있습니다. setExternalConnection 메소드를 사용해 mock 객체를 ConnectionManagenrT 객체에 세팅해두면 되는 것이죠.

그러니까 테스트 케이스 코드 안에서는 다음과 같은 짓을 순차적으로 하면 된다는 겁니다.

  PolicyAgent pa = new PolicyAgent();
  pa.initiate();

  ConnectionManagerT cm = new ConnectionManagerT(pa);

  ...

  final Connection connMock1 = context.mock( Connection.class );
  cm.addExternalConnection( connMock1 );

  //
  // test no-signature error scenario
  //

  context.checking( new Expectations() {{
   ...
  }});

  cm.run(); // 알고리즘 테스트

  ... // 수많은 assertion 코드들...

어떻습니까? 이렇게 하면 남의 코드를 몇줄 고치지 않고서도 테스트를 진행할 수 있습니다. new Connection 때리는 부분을 별도의 overridable 메소드로 분리하는 것 만으로, 테스트 가능성을 높인 코드를 만들 수 있다는 이야깁니다.

이런 가능성은 TDD 형태로 테스트 코드를 먼저 작성하건, 아니면 작성된 코드에 테스트 코드를 추가하건, 순서 불문하고 테스트 코드를 작성하느라 고민하지 않으면 좀처럼 열리지 않습니다. 의외로 테스트 가능한 코드를 만드는 것은 아주 간단한 리팩토링(Refactoring)으로부터 시작되는데도 말이죠.

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Extremely Agile/TDD2008.10.31 14:31

jMock은 Mock 객체를 이용해 테스트를 지원하는 라이브러리입니다. www.jMock.org에서 다운받으실 수 있습니다. 요즘 회사에서 '다른 사람이 작성한 코드'를 좀 더 '테스트 가능'(testable)하게 만드는 동시에 test coverage를 높이는 일을 하고 있습니다. 작년까지 했던 일과는 조금 다른 일이라, 재미있습니다.

jMock 계열의 라이브러리로는 EasyMock 같은 것도 있습니다만, 써보니까 'Easy'하다고 꼭 좋은것만도 아니어서 다시 jMock으로 돌아왔습니다. 돌아와보니 jMock이라고 또 그리 사용법이 복잡하지는 않습니다. 사용법이 좀 까다로와 보여서 진입장벽이 '약간' 있을 뿐이죠.

Mock 라이브러리를 사용해 테스트 코드를 작성하는 목적은, '테스트 대상 알고리즘을 그 알고리즘이 대상으로 하는 자원과 분리'하는 것이라고 볼 수 있겠습니다. 가령 알고리즘 foo가 어떤 자원 bar들을 대상으로 돌아간다고 해 봅시다. bar의 구현 상태와는 독립적으로, foo의 정확성만을 테스트하고 싶다고 해 봅시다. 그 경우에는 '원하는 대로 동작하는 것이 보장된' 가짜 bar 객체들만을 만들어 두고 그 위에서 foo를 돌리게 되면 foo의 정확성을 무리없이 검증할 수 있을 것입니다.

그러니 결국 Mock 라이브러리들이 하는 일은, '분리(separation)'라고 요약할 수 있겠습니다.

실제 '남의 코드'를 테스팅하는 사례를 살펴보기전에, 우선 jMock 라이브러리 사용법의 '골격'부터 알아보도록 하겠습니다. jMock라이브러리를 사용하기 위해서는, 대략 다음과 같은 클래스들을 임포트해 둘 필요가 있습니다. (뭐 eclipse가 알아서 다 해주긴 하지만..ㅎㅎ) 전 JUnit 4를 가지고 프로그래밍을 했기 때문에, JUnit4Mockery 클래스를 임포트하도록 했습니다.

import org.jmock.Expectations;
import org.jmock.Mockery;
import org.jmock.integration.junit4.JUnit4Mockery;
import org.jmock.lib.legacy.ClassImposteriser;

그런 다음 이제 JUnit 테스트 클래스의 안을 채워나가야 하는데요. ConnectionManager라는 클래스가 있다고 치고, 그 클래스를 테스트하는 JUnit4 클래스를 구현한다고 가정하겠습니다. 그 클래스 제일 윗부분에 다음과 같은 부분을 둡니다.

public class ConnectionManagerTest {

  private Mockery context = new JUnit4Mockery() {{
    // enable mocking of class also (not only interface!)
    setImposteriser(ClassImposteriser.INSTANCE);
  }};
  ...

}

보통 Mock 라이브러리들은 Interface 클래스를 인자로 받아, 그 인터페이스가 하는 일을 흉내내는 가짜 객체를 생성합니다. 그런데 EasyMock이나 JMock은 확장을 통해 일반 클래스를 인자로 받아서 Mock 객체를 생성할 수 있도록 배려하고 있습니다. 위의 적색으로 표시된 부분은, 일반 클래스를 인자로 받아 Mock 객체를 생성할 수 있도록 지시하는 부분이라고 생각하시면 됩니다.

이렇게 하고 나면 이제 테스트 코드를 작성하면 되는데요. 대략 다음과 같은 순서를 따릅니다.

 @Test
 public void testRun() throws Exception {

  // 1. Mock 객체 생성
  final Connection mock = context.mock( Connection.class );

  // 2. Mock 객체를 테스트 대상 알고리즘에 세팅
  ...
 
  // 3. 알고리즘을 돌렸을 때 mock 객체에 무슨 일이 일어나게 되는지를 명시
  context.checking( new Expectations() {{
   allowing (mock).getInteger(); will(returnValue(34));
   oneOf (mock).writeInteger(56);
   allowing (mock).close();

  }});

  // 4. 알고리즘 구동
  ...

  // 5. 각종 assert 문들 삽입
  ...
 }

우선, Mock 객체를 만듭니다. context.mock의 인자로 객체를 찍어낼 클래스를 인자로 넘겨주어야합니다. 그런 다음, 만들어진 mock 객체를 테스트 대상 알고리즘에 세팅합니다. 알고리즘을 구동할 때 mock 객체를 인자로 넘겨주게 되어 있다면, 이 단계를 생략해도 무방하겠습니다.

그런 다음, 알고리즘을 실제로 돌리면 mock 객체에 어떤 행위가 일어나게 되리라 '기대'(expectations)하는지를 세팅합니다. context.checking 메소드에 Expectations객체를 만들어 넘겨주는 식으로 세팅하게 되는데, 그 안에 발생할 것으로 기대되는 행위 목록을 적어주면 됩니다. 일단 위의 예제의 의미를 간단히 설명드리면,

allowing... 으로 시작되는 줄은, 알고리즘 구동 과정에서 mock 객체의 getInteger() 함수가 여러번 불리게 될 수 있는데, 그 때 마다 34를 리턴하도록(will(returnValue(34))) 지시하고 있습니다.
oneOf... 로 시작되는 줄은, 알고리즘 구동 과정에서 mock 객체의 writeInteger 함수가 단 한번 불리게 되는데, 그 때 인자로 56이 전달되어 호출되어야 함을 명시하고 있습니다.
마지막의 allowing...으로 시작되는 줄은, 알고리즘 구동 과정에서 mock 객체의 close() 함수가 여러번 불리게 될 수 있다는 것을 명시하고 있습니다.

결국, mock 객체가 알고리즘의 요구에 어떻게 반응하여야 하는지를 명시하는 셈입니다. 이 부분을 잘 작성해주면 mock 객체에 전달되는 값이 예상치와 일치하는 지를 검사하여 알고리즘이 제대로 된 값을 사용해 mock 객체와 통신하는지를 검사할 수 있게 되고, 결국 알고리즘의 정확성을 검증할 수 있게 됩니다.

이렇게 expectation의 목록을 작성하고 나면, 그 다음으로는 알고리즘을 구동시키고, assert구문들을 사용하여 (assertTrue, assertFalse 등) 구동 후의 상태가 예상한 것과 일치하는지를 보면 됩니다.

expection을 작성하는 문법이나, JMock 사용법에 대해 더 자세히 알고싶으신 분은 JMock 웹사이트에 올라온 cheat sheet를 보시면 좋을 것 같습니다.

[다음 글에 이어서...]

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 이상곤

    JMock에 대한 강좌 잘 읽었습니다. 헌데 따라 하는 중 ClassImposteriser 클래스를 임포트하는 과정에서 바로 막혔습니다. ㅠㅠ package가 org.jmock.lib.legacy 아래에 ClassImposteriser 있다고 나와 있고 API 문서를 봐도 그렇게 나와 있는데 stable 버전 2.5.1 jar 파일에는 그 이하에 legacy가 안보입니다. 혹시 제가 뭔가 간과 한 부분이 있는지요?

    2010.01.20 14:26 신고 [ ADDR : EDIT/ DEL : REPLY ]