336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
1. 개요
Spring Batch 기반의 배치 코드 중 일부분을 테스트 하는 예제이다. 위 코드 중 process의 파라메터가 바뀌기라도 하면 이 테스트는 수정되어야 한다. 따라서 process 하는 부분이 SUT와의 의존성이다. 그런데 한편 위 코드는 의존성 문제 관점에서 보면 이상적인 테스트이기도 하다. 왜냐하면 현재 SUT 중 테스트 하려는 메서드에만 의존성을 가지고 있는데 이 이상 의존성을 줄일수는 없기 때문이다. 사실 이 글에서 얘기하려는 것 중 많은 부분은 Mock 라이브러리의 사용으로 생기는 현상들에 대해서이다.
아래는 서비스를 ROS 상태로 중지시키는 시나리오를 테스트 하는 코드이다. 코드 중 'readOnlyStop'과 'readOnlyNottifer'는 'target.stop' 메서드 내부에서 사용하는 객체이다.
2. 구현에 의존적인 테스트를 만들지 말자
위에서 소개한 두 예제의 차이점은 첫째 예제가 구현에 의존적인 부분이 없는 반면, 둘째 예제는 구현에 의존적인 부분이 많다는 점이다. 첫째 예제는 상태검증이라 부르고, 둘째 예제는 행위검증이라 부른다. 그렇다면 항상 첫째 예제처럼 테스트를 작성하면 되는 것일까? 안타깝게도 불가능하다. 많은 경우 테스트를 하려면 부득불 둘째 예제처럼 작성해야만 한다. 아래 코드를 보자.
위 코드는 가상의 시나리오를 구현하는 코드로써 점검에 관련한 일을 한다. 하는 일은 간단한데 파라메터에 따라 일반점검 혹은 읽기가 가능한 점검 중 하나를 수행한다. 읽기가 가능한 점검 시에는 관련 된 서비스에 알림을 한다. 위 코드를 테스트해야 한다고 가정해보자. 특히 관련된 서비스에게 알림을 잘 했는지를 보장하는 것이 테스트의 가장 중요한 목적이라면 어떻게 테스트 해야 할까? 많은 경우 아래처럼 행위검증을 사용할 수 밖에 없다.
위 테스트는 해당 메서드가 정확히 실행되었는지를 보장해준다. 하지만 최종적으로 달성하려는 바는 같음에도 리팩토링 등을 통해 readOnlyNotifier가 아닌 다른 객체를 사용한다면 테스트의 실패와 개발자의 수정으로 이어질 것이다.
C) Tell, Don`t Ask 원칙
이 원칙은 Law of Demeter 원칙으로 많이 알려졌다. 또 최소지식의 원칙이라 부르기도 한다. 이 원칙을 내 표현으로 설명하면 다른 객체와 의사소통 할 때 지나치게 자세히 얘기하지 말고 가능한 간결하게 얘기하자는 것이다. 아래 코드를 보자.
when(readOnlyNotifier.relatedServices()).thenReturn(createRelatedServices());
when(readOnlyNotifier.notifyToRelatedServices(any(StopMessage.class))).
thenReturn(success);
4. 요약
결함유무와 관계없이 실패하는 테스트는 유지보수에 부담을 더한다. 이 부담은 테스트가 증가 할수록 심화될 수 있기 때문에 가볍게 볼 수 없는 부분이다. 사실 테스트가 SUT에 의존성을 갖는 것은 매우 자연스러운 일이다. 하지만 이 문제를 해결하지 않으면 유지보수 부담을 줄일 수 없다. 따라서 테스트를 작성할 때 가능한 SUT에 의존성하지 않도록 노력해야 한다. 이를 위해 앞서 소개한 통합 테스트, Mockito, Tell, Don`t Ask 원칙을 활용할 수 있다.
회사에서 테스트 지원을 하다보면 많은 개발자가 이미 만들어 놓은 테스트를 유지보수 하는데 꽤 많은 시간을 사용하고 있음을 볼 수 있다. 그 중에서도 실패한 테스트를 고치는 일이 잦다. 만약 어떤 결함이 존재할 때, 테스트가 그 결함으로 인해 실패하는 것은 매우 고무적인 일이다. 왜냐하면 테스트가 제 할 몫을 한 것이기 때문이다. 하지만 리팩토링 등으로 테스트 대상(이하 SUT, System Under Test)의 내부구현이 바뀜으로 결함유무와 관계없이 테스트가 실패하는 것은 안타까운 일이다. 이런 현상이 자주 발생하면 개발자는 테스트를 짐처럼 여기게 될 것이고, 나중에는 테스트가 정말로 가치있는지에 대한 고민을 시작할 것이다.
그렇다면 위와 같은 일이 왜 생길까? 이유는 의존성 때문이다. 테스트는 자연스레 SUT에 의존하는 부분이 생기고 이 의존성이 위 문제를 발생시킨다. 아래 테스트 코드를 보자.
그렇다면 위와 같은 일이 왜 생길까? 이유는 의존성 때문이다. 테스트는 자연스레 SUT에 의존하는 부분이 생기고 이 의존성이 위 문제를 발생시킨다. 아래 테스트 코드를 보자.
@Test
public void nameShouldBeModified() throws Exception {
final Integer id = 1;
Name name = new Name(id, "Min");
Name result = O.process(name);
assertThat(result, is(new Name(id, "Min-modified")));
}
public void nameShouldBeModified() throws Exception {
final Integer id = 1;
Name name = new Name(id, "Min");
Name result = O.process(name);
assertThat(result, is(new Name(id, "Min-modified")));
}
#1. Spring Batch 관련 상태기반 테스트
Spring Batch 기반의 배치 코드 중 일부분을 테스트 하는 예제이다. 위 코드 중 process의 파라메터가 바뀌기라도 하면 이 테스트는 수정되어야 한다. 따라서 process 하는 부분이 SUT와의 의존성이다. 그런데 한편 위 코드는 의존성 문제 관점에서 보면 이상적인 테스트이기도 하다. 왜냐하면 현재 SUT 중 테스트 하려는 메서드에만 의존성을 가지고 있는데 이 이상 의존성을 줄일수는 없기 때문이다. 사실 이 글에서 얘기하려는 것 중 많은 부분은 Mock 라이브러리의 사용으로 생기는 현상들에 대해서이다.
아래는 서비스를 ROS 상태로 중지시키는 시나리오를 테스트 하는 코드이다. 코드 중 'readOnlyStop'과 'readOnlyNottifer'는 'target.stop' 메서드 내부에서 사용하는 객체이다.
@Test
public void serviceShouldBeStopped_WhenNeedingReadOnlyStop() {
when(readOnlyStop.stopNow()).thenReturn(success);
when(readOnlyNotifier.relatedServices()).thenReturn(createRelatedServices());
when(readOnlyNotifier.notifyToRelatedServices(any(StopMessage.class))).
thenReturn(success);
target.stop(readOnlyStopType, "Read Only Stop");
verify(readOnlyStop).stopNow();
}
public void serviceShouldBeStopped_WhenNeedingReadOnlyStop() {
when(readOnlyStop.stopNow()).thenReturn(success);
when(readOnlyNotifier.relatedServices()).thenReturn(createRelatedServices());
when(readOnlyNotifier.notifyToRelatedServices(any(StopMessage.class))).
thenReturn(success);
target.stop(readOnlyStopType, "Read Only Stop");
verify(readOnlyStop).stopNow();
}
#2. 의존성이 많은 행위기반 테스트
위 테스트는 많은 개발자가 즐겨쓰는 Mock 라이브러리인 Mockito를 이용하여 행위검증을 하는 예이다. 위 테스트 코드를 보면 테스트가 메서드 내부에 있는 동작에 지나치게 의존하고 있는 것을 볼 수 있다. 좀더 정확하게 표현하자면 위 5줄 모두가 의존성이다. 따라서 SUT의 메서드가 리팩토링이 된다면 위 테스트는 십중팔구 컴파일 오류가 나거나 실패할 것이고, 개발자는 결국 테스트 코드를 수정해야 할 것이다.
켄트벡은 "Where, Oh Where to Test?" 라는 글에서 이 문제를 세련스럽게 Stability 라는 단어로 표현했다. Stability 문제는 두 가지 경우를 포함한다. 첫째는 테스트가 성공했는데 결함이 있는 경우이고, 둘째는 테스트가 실패했는데 결함이 없는 경우이다. 둘의 공통점은 테스트가 잘못된 피드백을 주었고 결과로 불필요한 낭비가 생겼다는 것이다. 앞서 리팩토링 후 테스트 코드의 컴파일이 실패하거나 테스트가 실패하는 경우를 언급했다. 나는 이 경우가 테스트가 실패했음에도 실제로는 결함이 아닌 경우라 생각한다. 왜냐하면 결함 여부와 관계없이 단지 구현이 바뀜으로 인해 테스트가 실패했기 때문이다.
지금까지 얘기한 문제는 단순해보일지도 모른다. 하지만 유지보수에 많은 부담을 주는 부분이다. 그럼 어떻게 하면 Stability 문제를 해결할 수 있을까? 본인은 두 가지 방향이 있다고 생각한다.
2. 구현에 의존적인 테스트를 만들지 말자
위에서 소개한 두 예제의 차이점은 첫째 예제가 구현에 의존적인 부분이 없는 반면, 둘째 예제는 구현에 의존적인 부분이 많다는 점이다. 첫째 예제는 상태검증이라 부르고, 둘째 예제는 행위검증이라 부른다. 그렇다면 항상 첫째 예제처럼 테스트를 작성하면 되는 것일까? 안타깝게도 불가능하다. 많은 경우 테스트를 하려면 부득불 둘째 예제처럼 작성해야만 한다. 아래 코드를 보자.
public void stop(StopType stopType, String reason) {
validate(stopType, reason);
if (stopType == StopType.COMPLETE_STOP) {
stopNowQuietly(completeStop, whenFailedMessageIs(""));
} else if (stopType == StopType.READONLY_STOP) {
stopNowQuietly(readOnlyStop, whenFailedMessageIs("ROS"));
readOnlyNotifier.notifyIfThereAreRelatedSerivcesUsing(createMessageBy(reason));
}
}
validate(stopType, reason);
if (stopType == StopType.COMPLETE_STOP) {
stopNowQuietly(completeStop, whenFailedMessageIs(""));
} else if (stopType == StopType.READONLY_STOP) {
stopNowQuietly(readOnlyStop, whenFailedMessageIs("ROS"));
readOnlyNotifier.notifyIfThereAreRelatedSerivcesUsing(createMessageBy(reason));
}
}
#3. 어떤 서비스의 점검을 시작하는 메서드
위 코드는 가상의 시나리오를 구현하는 코드로써 점검에 관련한 일을 한다. 하는 일은 간단한데 파라메터에 따라 일반점검 혹은 읽기가 가능한 점검 중 하나를 수행한다. 읽기가 가능한 점검 시에는 관련 된 서비스에 알림을 한다. 위 코드를 테스트해야 한다고 가정해보자. 특히 관련된 서비스에게 알림을 잘 했는지를 보장하는 것이 테스트의 가장 중요한 목적이라면 어떻게 테스트 해야 할까? 많은 경우 아래처럼 행위검증을 사용할 수 밖에 없다.
...
verify(readOnlyNotifier).notifyIfThereAreRelatedSerivcesUsing(..);
...
verify(readOnlyNotifier).notifyIfThereAreRelatedSerivcesUsing(..);
...
#4. 3번 코드를 대상으로 알림을 했는지 여부를 검증하는 코드
위 테스트는 해당 메서드가 정확히 실행되었는지를 보장해준다. 하지만 최종적으로 달성하려는 바는 같음에도 리팩토링 등을 통해 readOnlyNotifier가 아닌 다른 객체를 사용한다면 테스트의 실패와 개발자의 수정으로 이어질 것이다.
이럴 때 사용할 수 있는 대안은 통합 테스트이다. 통합 테스트를 이용하면 메서드를 실제로 실행시킬 수 있으며 어떻게(How)가 아닌 무엇(What)에 집중할 수 있는 기회를 얻는다. 다시 말해 특정 목적을 달성하려고 구현한 방법이 아닌 달성 결과를 기반으로 검증할 수 있게 된다. 그렇다면 위 예는 통합 테스트에서 어떻게 검증할 수 있을까? 메서드 호출 후 남는 전송결과로그를 살펴보면 어떨까? 전송로그결과 파일 안에 방금 전송한 로그가 존재하는 것을 확인하는 것이다. 이렇게 하면 테스트는 예전처럼 행위검증이 아닌 상태검증을 하게 된다. 그 결과로 내부구현에 대한 의존성이 사라진다. 상태검증으로 변경 된 코드는 아래와 같다.
...
verify(readOnlyNotifier).notifyIfThereAreRelatedSerivcesUsing(..);
assertThat(logInFile, is(existing()));
...
verify(readOnlyNotifier).notifyIfThereAreRelatedSerivcesUsing(..);
assertThat(logInFile, is(existing()));
...
#5. 4번의 검증 코드를 상태 기반 검증으로 변환
하지만 통합 테스트는 단점이 있다. 첫째는 실행시간의 증가이다. 위 예의 경우 실제로 로깅을 하고 관련 서비스에 메세지를 보내려면 아무래도 단위 테스트보다는 실행시간이 오래 걸리게 된다. 테스트의 실행시간이 오래 걸리는 것은 개발자가 개발 시 받는 피드백 속도를 둔화시키고 결국 생산성 저하로 이어질 수 있다. 둘째는 오류가 났을 때 어디에 문제가 생겼는지 알기 어렵다는 점이다. 통합 테스트의 특성상 많은 영역이 실행될 것이고 그 중 한 군데라도 결함이 생기면 테스트는 실패할 것이다. 하지만 이 때 결함이 어떤 부분에 생겼는지 명확하지 않다는 것이 문제다. 단위 테스트가 잘 고립되어 있을 때 테스트가 실패하면 문제점은 테스트 실행 대상 내에 있다고 단정할 수 있는 것과는 대조적이다. 마지막 문제는 SUT가 아닌 다른 곳이 의존성이 생길 수 있다는 점이다. 위 예에서는 로그파일에 대한 추가 의존성이 생겼다.
사실 위와 같은 단점 때문에 통합 테스트와 행위 기반의 단위 테스트를 비교하다보면 의존성 문제를 감안하더라도 행위검증을 선택하는 경우도 많다. 이 경우에는 아래 방향을 따르면 좋다.
3. 구현에 의존적인 테스트를 만들어야 한다면 최대한 의존하는 부분을 줄이며 테스트를 만들자
A) Mockito 사용
A) Mockito 사용
Mockito는 최근 들어 많은 사랑을 받고 있는 듯 하다. 사내에 EasyMock, JMock을 사용하는 개발팀도 있지만 최근에는 많은 개발팀이 Mockito를 선택하고 있다. Mockito에는 다른 경쟁 라이브러리와 비교되는 특징이 몇 가지 있다. 그 중 의존성 관점에서 주목할 만한 점은 Mockito 홈페이지에 있는 "Verify what you want"라는 인상적인 문구와 함께 소개 된 특징이다. 이런 Mockito의 특징을 보려면 다른 라이브러리와 비교하는 것이 좋을 것 같아 JMock과 비교하는 예제를 준비했다.
public void moveArticle(Integer articleId) {
Article article = articleDAO.findBy(articleId);
if (article.movable()) {
articleDAO.updateArticle(article);
articleDAO.updateAttachedFiles(article);
articleDAO.updateAttachedPics(article);
}
}
Article article = articleDAO.findBy(articleId);
if (article.movable()) {
articleDAO.updateArticle(article);
articleDAO.updateAttachedFiles(article);
articleDAO.updateAttachedPics(article);
}
}
#6. 아티클을 이동하는 메서드
위 코드는 실제 프로젝트에서 가져와 약간의 변형을 가한 코드이다. 하는 일을 간단히 설명하자면 아티클을 찾은 후 아티클의 이동이 가능하다면 이동을 하는 예이다. 테스트에 경험이 있는 사람은 금방 알 수 있지만 행위검증이 필요한 경우이다. 이 코드를 보면 크게 두 가지 흐름이 있음을 알 수 있다. 아티클이 이동 가능한 경우와 이동이 불가능한 경우이다. 이동이 가능할 때는 아티클 정보를 업데이트 하지만, 불가능하면 아무것도 하지 않는다. JMock을 이용하여 이 두 가지 흐름 중 이동 가능한 경우를 테스트 해보았다.
@Test
public void articleShouldBeMoved() {
context.checking(new Expectations() {
{
oneOf(articleDAO).findBy(articleId);
will(returnValue(article));
oneOf(article).movable();
will(returnValue(Boolean.TRUE));
oneOf(articleDAO).updateArticle(article);
oneOf(articleDAO).updateAttachedFiles(article);
oneOf(articleDAO).updateAttachedPics(article);
}
});
sut.moveArticle(articleId);
context.assertIsSatisfied();
}
public void articleShouldBeMoved() {
context.checking(new Expectations() {
{
oneOf(articleDAO).findBy(articleId);
will(returnValue(article));
oneOf(article).movable();
will(returnValue(Boolean.TRUE));
oneOf(articleDAO).updateArticle(article);
oneOf(articleDAO).updateAttachedFiles(article);
oneOf(articleDAO).updateAttachedPics(article);
}
});
sut.moveArticle(articleId);
context.assertIsSatisfied();
}
#7. JMock을 이용하여 아티클을 이동하는 메서드를 테스트
JMock은 Expectations를 이용하여 Stubbing과 Verifying을 한다. 위에서 보면 위가 Stubbing 하는 부분이고 아래가 Verifying하는 부분이다. 이 코드를 읽어보면 'moveArticle'을 호출한 후 관련된 모든 메서드가 잘 실행되었는지 검증을 한다는 것을 확인할 수 있다. 이후 만약 개발자가 코드를 수정하다 실수로 'updateAttachedFiles'를 수행 안 하기라도 하면 바로 오류가 날 것이다. JMock을 이용하여 엄격한 검증을 하고 있기 때문이다. Expectations안에 있는 코드는 내부의 수행되어야 하는 모든 행위를 그대로 표현하고 있다. 하지만 이게 좋은 것일까?
JMock에 대한 관심에서 잠시 벗어나 이 얘기를 처음 시작했던 의존성 문제를 생각해보자. 위 코드를 보면 바로 알수 있듯이 의존성 투성이다. articleDAO가 내부에서 하는 모든 행위가 기록되어 있다. 의존성 관점에서는 별로 탐탁치 않은 부분이다. 그렇다면 테스트를 하지 말자는 것인가? 그것은 아니다. 다만 본인은 위 테스트를 조금 느슨하게 할 수 있다고 생각한다. 예를 들어 테스트의 목적을 잘 생각해보면 중요한 부분은 메서드 내부의 movable에 따른 분기로 볼 수 있다. 이동이 가능할 때는 'updateArticle', 'updateAttachedFiles', 'updateAttachedPics'가 있는 코드블락으로 진입해야 한다. 그렇다면 코드블락으로 진입하는지 여부만 테스트를 하면 어떨까? 좀더 구체적으로 'updateArticle'이 호출된다면 그 아래도 당연히 호출 될 테니 아래와 같이 코드를 고치면 좋을 것 같다.
@Test
public void articleShouldBeMoved() {
context.checking(new Expectations() {
{
oneOf(articleDAO).findBy(articleId);
will(returnValue(article));
oneOf(article).movable();
will(returnValue(Boolean.TRUE));
oneOf(articleDAO).updateArticle(article);
oneOf(articleDAO).updateAttachedFiles(article);
oneOf(articleDAO).updateAttachedPics(article);
}
});
sut.moveArticle(articleId);
context.assertIsSatisfied();
}
public void articleShouldBeMoved() {
context.checking(new Expectations() {
{
oneOf(articleDAO).findBy(articleId);
will(returnValue(article));
oneOf(article).movable();
will(returnValue(Boolean.TRUE));
oneOf(articleDAO).updateArticle(article);
oneOf(articleDAO).updateAttachedFiles(article);
oneOf(articleDAO).updateAttachedPics(article);
}
});
sut.moveArticle(articleId);
context.assertIsSatisfied();
}
#8. JMock의 엄격한 검증으로 인해 실패하는 테스트
하지만 테스트를 돌려보면 오류가 나는 것을 확인할 수 있다. 오류 내용은 'updateAttachedFiles', 'updateAttachedPics'가 실제로 호출 되었는데 테스트에는 이런 부분에 대한 언급이 없었다는 점을 지적한다. JMock은 기본적으로 이렇게 엄격한 검증을 수행한다. 이어 Mockito의 코드를 보자.
@Test
public void articleShouldBeMoved() {
when(articleDAO.findBy(articleId)).thenReturn(article);
when(article.movable()).thenReturn(Boolean.TRUE);
sut.moveArticle(articleId);
verify(articleDAO).updateArticle(article);
}
public void articleShouldBeMoved() {
when(articleDAO.findBy(articleId)).thenReturn(article);
when(article.movable()).thenReturn(Boolean.TRUE);
sut.moveArticle(articleId);
verify(articleDAO).updateArticle(article);
}
#9. Mockito를 이용하여 아티클을 이동하는 메서드를 테스트
위 코드를 보면 방금 전 얘기했던 느슨한 검증에 관한 아이디어가 그대로 적용되어 있음을 볼 수 있다. 'moveArticle'을 한 후 'updateArticle'이 호출되었는지만 검사하고 있다. 결과로 테스트가 SUT에 의존하던 코드가 줄었다.
B) Mockcito의 느슨한 검증 활용
Mockito의 느슨한 검증을 활용할 수 있는 예가 하나 더 있다. 아래 코드를 보자.
@Test
public void serviceShouldBeStopped_WhenNeedingReadOnlyStop() {
when(readOnlyStop.stopNow()).thenReturn(success);
target.stop(readOnlyStopType, "Read Only Stop");
verify(readOnlyStop).stopNow();
}
public void serviceShouldBeStopped_WhenNeedingReadOnlyStop() {
when(readOnlyStop.stopNow()).thenReturn(success);
target.stop(readOnlyStopType, "Read Only Stop");
verify(readOnlyStop).stopNow();
}
#10. 내부구현에 의존하는 코드가 2회 반복해서 등장
위 테스트의 진한 부분을 보면 'readOnlyStop.stopNow'이 첫줄과 마지막 줄에 반복해서 등장하는 것을 확인할 수 있다. 혹시 그 중 하나는 제거할 수 있지 않을까? 이 경우 SUT의 코드가 어떻게 되었느야에 따라 의존성을 좀더 제거할 수도 있다. 제거가 가능한지 확인하기 위해 아래 SUT의 코드를 보자.
if (readOnlyStop.stopNow()) {
...
} else {
throw new FailedStopException("Cannot stop the service.");
}
...
} else {
throw new FailedStopException("Cannot stop the service.");
}
#11. 방금 전 테스트가 테스트 하는 대상
위 코드는 앞에서 소개 된 점검 예제의 한 부분이다. 살펴보면 'readOnlyStop.stopNow'가 True를 반환하지 않으면 예외가 발생되게 되어있다. 이 경우 verify를 이용하여 readOnlyStop의 stopNow가 호출되었는지를 검사하지 않아도 해당 메서드가 제대로 호출되지 않으면 예외가 발생할 것이다. 다시 말해 앞서 소개한 'when(readOnlyStop.stopNow()).thenReturn(success);'가 제대로 수행되지 않으면 False가 반환 될 것이고 예외가 발생하여 테스트는 실패할 것이다. 따라서 verify부분을 제거해도 된다는 결론에 이르게 된다. 이는 대부분의 Mock 라이브러리와 마찬가지로 Mockito는 Mock 객체에 Stubbing이 되어있지 않으면 False나 Null 등을 반환하게 되어있기 때문에 가능한 일이다. 결국 테스트 코드는 아래와 같이 변경될 수 있다.
@Test
public void serviceShouldBeStopped_WhenNeedingReadOnlyStop() {
when(readOnlyStop.stopNow()).thenReturn(success);
target.stop(readOnlyStopType, "Read Only Stop");
verify(readOnlyStop).stopNow();
}
public void serviceShouldBeStopped_WhenNeedingReadOnlyStop() {
when(readOnlyStop.stopNow()).thenReturn(success);
target.stop(readOnlyStopType, "Read Only Stop");
verify(readOnlyStop).stopNow();
}
#12. verify 부분이 제거되어 보다 의존성이 줄어든 테스트
이렇게 Mockito를 잘 활용하면 의존성을 완화할 수 있다. 다만 주의할 점은 Mockito를 이용하여 느슨한 검증을 할 때 테스트 목적이 훼손되지 않도록 조심해야 한다는 것이다. 예를 들어 느슨한 검증을 하다 제대로 된 검증을 하지 못하는 테스트를 만들수도 있다. 만약 테스트를 만들었는데 조금 의아스럽다면 뮤테이션 테스트를 이용하여 테스트를 검증해보는 것이 좋다.
C) Tell, Don`t Ask 원칙
이 원칙은 Law of Demeter 원칙으로 많이 알려졌다. 또 최소지식의 원칙이라 부르기도 한다. 이 원칙을 내 표현으로 설명하면 다른 객체와 의사소통 할 때 지나치게 자세히 얘기하지 말고 가능한 간결하게 얘기하자는 것이다. 아래 코드를 보자.
public void stop(Integer type, String reason) {
...
if (readOnlyNotifier.relatedServices().size() > 0) {
if (readOnlyNotifier.notifyToRelatedServices(stopMessage) == false) {
throw new FailedReadOnlyNotificationException();
}
}
}
...
if (readOnlyNotifier.relatedServices().size() > 0) {
if (readOnlyNotifier.notifyToRelatedServices(stopMessage) == false) {
throw new FailedReadOnlyNotificationException();
}
}
}
#13. readOnlyNotifier에게 과다하게 의존적인 코드
'...'으로 생략 된 부분을 제외한 나머지 코드 부분의 테스트를 만든다고 가정해보자. 어떻게 하면 될까? 우선 실행흐름을 보자. 잘 보면 위 코드만 가지고도 테스트 해야 할 흐름이 세 가지나 있다. 그중 관련 서비스가 한 개 이상 있어 알림을 해야하는 흐름을 테스트 한다고 생각해보자. Mockito를 이용하여 아래와 같이 테스트 코드를 작성했다. 앞서 Mockito를 소개하며 언급했던 느슨한 검증이 가능한 특징으로 인해 verify 부분이 없는 것에 유의한다.
@Test
public void stopEventShouldBeNotifiedToRelatedServices() {
when(readOnlyNotifier.relatedServices()).thenReturn(createRelatedServices());
when(readOnlyNotifier.notifyToRelatedServices(any(StopMessage.class))).
thenReturn(success);
target.stop(readOnlyStopType, "Stop For Testing");
}
public void stopEventShouldBeNotifiedToRelatedServices() {
when(readOnlyNotifier.relatedServices()).thenReturn(createRelatedServices());
when(readOnlyNotifier.notifyToRelatedServices(any(StopMessage.class))).
thenReturn(success);
target.stop(readOnlyStopType, "Stop For Testing");
}
#14. 위 코드에 대한 테스트 코드
이 테스트의 의존성을 더 줄일 수 있을까? Tell, Don`t Ask 원칙을 도입하면 가능하다. 위 SUT의 문제점은 'stop' 메서드에서 'readOnlyNotifier에게 관련된 서비스가 있는지 묻고' 난 후 그 결과에 따라 메세지를 보낸다는 점이다. 묻고 보내기 때문에 두 클래스 간의 접점이 두 군데가 된다. 그런데 여기에 Tell, Don`t Ask 원칙을 적용하면 물어보지 않고 단순히 요청을 말하게 된다. 접점을 한 군데로 줄일 수 있다. 이를 위해 SUT의 코드를 아래와 같이 수정하고, 기존 코드는 readOnlyNotifier로 이동시킨다.
public void stop(Integer type, String reason) {
...
readOnlyNotifier.notifyIfThereAreRelatedServices(stopMessage);
}
public class ReadOnlyNotifier {
...
public void notifyIfThereAreRelatedServices(StopMessage stopMessage) {
...
readOnlyNotifier.notifyIfThereAreRelatedServices(stopMessage);
}
public class ReadOnlyNotifier {
...
public void notifyIfThereAreRelatedServices(StopMessage stopMessage) {
if (this.relatedServices().size() > 0) {
if (this.notifyToRelatedServices(stopMessage) == false) {
throw new FailedReadOnlyNotificationException();
}
}
if (this.notifyToRelatedServices(stopMessage) == false) {
throw new FailedReadOnlyNotificationException();
}
}
}
...
}
#15. Tell, Don`t Ask 원칙의 적용
예전과 같이 묻지 않고 그냥 'readOnlyNotifier'에게 일을 맡기고 있다. 즉, 해당 코드가 하던 일이 'readOnlyNotifier'로 이동 된 것이다. 결과로 코드가 매우 간결해졌고 커플링도 줄어들었다. 이렇게 커플링이 줄어들면 이후 리팩토링 할 때도 서로간의 간섭이 별로 없어 좋다. 최종적으로 테스트 코드는 아래처럼 의존성이 더 줄어든다.
@Test
public void stopEventShouldBeNotifiedToRelatedServices() {
when(readOnlyNotifier.notifyIfThereAreRelatedServices(any(StopMessage.class))).
thenReturn(success);
target.stop(readOnlyStopType, "Stop For Testing");
}
#16. Tell, Don`t Ask 원칙의 적용으로 인해 처음과 비교해 의존성이 줄어든 테스트
4. 요약
결함유무와 관계없이 실패하는 테스트는 유지보수에 부담을 더한다. 이 부담은 테스트가 증가 할수록 심화될 수 있기 때문에 가볍게 볼 수 없는 부분이다. 사실 테스트가 SUT에 의존성을 갖는 것은 매우 자연스러운 일이다. 하지만 이 문제를 해결하지 않으면 유지보수 부담을 줄일 수 없다. 따라서 테스트를 작성할 때 가능한 SUT에 의존성하지 않도록 노력해야 한다. 이를 위해 앞서 소개한 통합 테스트, Mockito, Tell, Don`t Ask 원칙을 활용할 수 있다.
WRITTEN BY
- 차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!
,
