1. 개요



Spring Batch 기반의 배치 코드 중 일부분을 테스트 하는 예제이다. 위 코드 중 process의 파라메터가 바뀌기라도 하면 이 테스트는 수정되어야 한다. 따라서 process 하는 부분이 SUT와의 의존성이다. 그런데  한편 위 코드는 의존성 문제 관점에서 보면 이상적인 테스트이기도 하다. 왜냐하면 현재 SUT 중 테스트 하려는 메서드에만 의존성을 가지고 있는데 이 이상 의존성을 줄일수는 없기 때문이다. 사실 이 글에서 얘기하려는 것 중 많은 부분은 Mock 라이브러리의 사용으로 생기는 현상들에 대해서이다.

아래는 서비스를 ROS 상태로 중지시키는 시나리오를 테스트 하는 코드이다. 코드 중 'readOnlyStop'과 'readOnlyNottifer'는 'target.stop' 메서드 내부에서 사용하는 객체이다.




2. 구현에 의존적인 테스트를 만들지 말자

위에서 소개한 두 예제의 차이점은 첫째 예제가 구현에 의존적인 부분이 없는 반면, 둘째 예제는 구현에 의존적인 부분이 많다는 점이다. 첫째 예제는 상태검증이라 부르고, 둘째 예제는 행위검증이라 부른다. 그렇다면 항상 첫째 예제처럼 테스트를 작성하면 되는 것일까? 안타깝게도 불가능하다. 많은 경우 테스트를 하려면 부득불 둘째 예제처럼 작성해야만 한다. 아래 코드를 보자.



위 테스트는 해당 메서드가 정확히 실행되었는지를 보장해준다. 하지만 최종적으로 달성하려는 바는 같음에도 리팩토링 등을 통해 readOnlyNotifier가 아닌 다른 객체를 사용한다면 테스트의 실패와 개발자의 수정으로 이어질 것이다.

HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms.

http://tools.ietf.org/html/rfc2045#section-5

The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type. 

Webwork에는 재밌는 기능이 하나 있습니다. 그것은 요청 파라메터를 모델 객체로 바로 매핑 시켜주는 기능입니다. 예제 코드를 만들어 보았습니다.

public class Param extends ActionSupport {

    private final static Log log = LogFactory.getLog(Param.class);
    private Person person;
   
    public String execute() {
        log.info(person.getName());
        log.info(person.getAge());
        return SUCCESS;
    }
    public Person getPerson() {
        return person;
    }

    public void setPerson(Person person) {
        this.person = person;
    }

    private class Person {
        private String name;
        private Integer age;

        public Integer getAge() {
            return age;
        }
        public void setAge(Integer age) {
            this.age = age;
        }
        public String getName() {
            return name;
        }
        public void setName(String name) {
            this.name = name;
        }
    }
}

위와 같은 액션을 만든 후 아래와 같이 접근해보면,
http://localhost:8080/Param.action?person.name=Min&person.age=90

콘솔에 이름과, 나이가 찍히게 됩니다. GET파라메터가 객체로 바로 매핑 된 것입니다. 내부적으론 Person객체의 setter들이 호출 될 것입니다.

처음 보았을 때는 상당히 유용한 기능이라고 생각했습니다. 반복되는 코드의 작업을 줄여줄 것이라 생각했기 때문입니다. 하지만 좀 더 사용하다보니 절대 사용하지 말아야 하는 기능 중에 하나라고 생각하게 되었습니다.

이유는 "모델 객체가 요청 파라메터의 영역으로까지 영향을 미치게 되었기 때문"입니다. 즉 모델과 요청 파라메터 사이에는 강한 결합(Tight coupling)이 발생한 것입니다. 만약 위의 person.name, person.age와 같은 파라메터가 여기 저기(JSP or JS 등)에서 사용되고 있는 상황에서, 어떤 이유로 Person 객체의 name 필드가 nickname으로 수정되고 setter 또한 setNickname으로 수정되어야 한다고 가정 해봅시다. 이 때 여기 저기 노출되어 있는 파라메터명이 모두 수정(person.name->person.nickname)되어야 합니다. 아마 단순히 서블릿만을 사용해 본 신입 개발자도 의아한 표정으로 물어볼 것입니다.

"모델 클래스를 변경했을 뿐인데 왜 파라메터명들이 모두 바뀌어야하죠? 제 서블릿 코드는 자바 코드만 고치면 되는데요."

그렇습니다. 지금 상황에선 차라리 예전 서블릿에서 많이 쓰던 아래와 같은 코드가 낫습니다.

String name = request.getParameter("name");
String age = request.getParameter("age");
Person person = new Person();
person.setName(name);
person.setAge(age);

(참고. 서블릿과 구 프로그래밍 방식이 무조건 좋다는 말은 아닙니다. 요청과 모델 사이에 매핑 코드가 존재하는 구조가 좋다는 말입니다.)

위와 같은 코드는 모델이 바뀐다고 요청 파라메터까지 바뀌지 않아도 됩니다. 우리는 이것을 흔히 "느슨한 결합( Loose coupling)"이라고 얘기합니다. 사실 원래 신경쓰지 않아도 우리가 늘 해온대로만 코딩해도 느슨하게 이루어지던 부분입니다. 그런데 위의 경우에는 소위 새로운 무엇이라고 불리는 것이 오히려 기존의 장점을 없애고 해악을 끼쳤다고 볼 수 있겠습니다.

그렇기 때문에 우리는 새로운 기술을 적용할 때 좀더 신중해야합니다. 새로운 것이 항상 긍정적인 효과만을 가져다주진 않기 때문입니다. 그리고 위 서블릿의 예에서 볼 수 있듯이 오래된 방식이라고 해서 항상 퇴출해야 하는 것만은 아닙니다. 오래된 것은 오래된 것 나름대로의 숙성된 향이 있기 때문입니다. :)

예상 반론. 누군가는 변화가 발생했을 때 기존의 setter 인터페이스를 그대로 유지하면서 새로운 인터페이스로 위임하면 되지 않겠느냐고 말할 수 있겠습니다. 물론 이것은 분명히 하나의 해결책이 될 수 있습니다. 하지만 좋은 해결책은 아닙니다. setter가 많아짐으로 인해 클래스의 복잡도(setter가 많은 것도 복잡도가 높아지는 요인이라고 생각합니다)가 증가하기 때문입니다. 또한 구 setter들 위에 다른 개발자를 위해 주석을 달아놔야 할 것입니다. "기존 웹 파라메터와의 호환성을 위해 유지함"이라고 말입니다.

이 후 로컬 환경에는 클라이언트 모드를 사용하고 있습니다만, 사실 속도차를 체감하진 못합니다. 그래도 서버 모드보다는 나을 것입니다. 필요없이 복잡한 최적화를 하지 않을테니까요. :)

저는 테스트 철학이니 TDD니 이런 것들은 잘 모릅니다. 그렇지만 테스트가 좋습니다. 왜냐하면 테스트는 제가 해야 할 반복적인 일을 줄여주고 제가 좀더 재미있어 하는 문제에 집중할 수 있게 도와주기 때문입니다. 그러므로 제게 있어 테스트는 무척 "실용적"입니다. 저는 테스트를 자신있게 추천합니다.