<div id="readability-page-1" class="page"><div><img src="https://velog.velcdn.com/images/joosing/post/7458737b-fd86-46e9-afda-02054c2a6947/image.png">
이 글에서는 비동기 시스템의 테스트 코드를 개선해 나간 과정을 소개합니다. 이 과정의 끝에는 <a href="https://github.com/awaitility/awaitility">Awaitility</a> 라는, 스스로를 테스트 라이브러리가 아닌 DSL(Domain-specific language)이라 소개하는 기술이 있는데 Awaitility를 사용해서 아주 읽기 좋고, 간결한 테스트 코드를 작성할 수 있었습니다. 
<h2 id="비동기-시스템-특징">비동기 시스템 특징</h2>
우리가 API 시스템에 어떤 변경 명령을 보내고, 응답을 받는 상황을 생각해 봅시다. 동기(Sync) 시스템에서 응답은 “요청에 대한 처리가 완료 되었어” 라는 의미를 담고 있습니다. 반면 비동기(Async) 시스템에서 응답은 “요청을 잘 받았고, 단지 처리를 시작 했어” 라는 다른 의미를 담고 있습니다. 그렇기 때문에 비동기 시스템에서는 명령에 대한 응답을 받았다고 해서 변경이 완료되었다고 가정할 수 없고, 추후 어떤 방법으로든 결과를 체크해야하는 구조적인 특징을 가집니다.
<img src="https://velog.velcdn.com/images/joosing/post/a4285966-e048-405e-bc5c-4726c1c51ea0/image.png">
<h2 id="비동기-시스템-테스트-코드">비동기 시스템 테스트 코드</h2>
따라서 우리가 비동기 시스템의 상태를 변경하는 동작을 테스트할 때에는 동기적인 코드를 테스트할 때와는 다른 패턴의 코드를 작성하게 됩니다. 
<h3 id="동기식-테스트">동기식 테스트</h3>
동기식 시스템에서는 상태변경 명령을 보내고 간단하게 즉시 결과를 확인할 수 있습니다. 
<pre><code>@Test
void status_reflects_commanded_value() {
 // 1. When - 상태 변경 명령 전송
 target.send(new ChangeCommand(100));

 // 2. Then - 상태 변경 여부 확인
	assertEquals(100, target.readStatus());
}</code></pre>
<h3 id="비동기식-테스트">비동기식 테스트</h3>
반면에 비동기식 시스템에서는 상태 변경 명령을 보낸 후, 일정 시간 동안 시스템이 원하는 상태로 변경 되었는지 반복해서 체크해야 합니다. 
<blockquote>
API 시스템에서 이벤트 리스너를 등록하고 처리 완료 알람을 주는 방법을 지원한다면 테스트가 더 간단해 질 수 있습니다. 그러나 그렇지 않은 경우 아래와 같이 직접 반복적으로 상태를 체크하는 폴링(Polling) 방식을 사용해야 합니다. 이 글은 폴링해야 하는 비동기 시스템을 테스트하는 예입니다.
</blockquote>
<pre><code>@Test
void status_reflects_commanded_value() {
 // 1. When - 상태 변경 명령 전송
 target.send(new ChangeCommand(100));

 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 long startMillis = System.currentTimeMillis();
 while (System.currentTimeMillis() - startMillis &lt; 2000) {
 if (target.readStatus() == 100) {
 // 성공
 return;
 }
 }

 // 3. (실패 시) 실패 판정에 사용된 값 출력
	log.info("status : {}", target.readStatus());
 fail();
}</code></pre>
<h2 id="라이브러리-직접-만들기">라이브러리 직접 만들기</h2>
위의 코드를 잠시 살펴보면 앞으로 중복될 코드들이 너무 많습니다. 비동기적인 상태 변경을 반복 체크하는 코드 조각(주석 2)에서 “target.readStatus() == 100” 부분 외에는 매 번 반복될 것이고, 실패 판정에 사용된 값을 출력하는 코드 조각(주석 3)에서도 “status : {}", target.readStatus()” 상태 문자열 외에는 모두 중복될 것입니다. 그래서 변경되지 않는 부분은 템플릿으로 만들고, 변경되는 부분은 콜백으로 받아 처리하는 자체 라이브러리를 만들었습니다. (아래 코드는 라이브러리의 초기 모습은 아니고, 최근에 JUnit의 구현을 보고 유사한 스타일로 재구성한 모습입니다)
<pre><code>public class AssertUntilTimeout {

 /**
 * 제한시간(timeout) 동안 특정 조건을 만족(assertOnce)하는지 반복 확인합니다. 조건 만족 시 즉시 실행을 반환하고, 타임아웃 시 테스트
 * 실패를 알리는 예외를 던집니다.
 *
 * @param timeout 제한시간
 * @param assertOnce 한 번 조건을 확인하는 함수
 * @param messageSupplier 실패 메시지 생성 함수
 */
 public static void assertUntilTimeout(Duration timeout, AssertionSupplier assertOnce, Supplier&lt;String&gt; messageSupplier) {
 if (!tryUntilTimeout(timeout, assertOnce)) {
 buildAndThrowAssertionFailure(timeout, messageSupplier);
 }
 }

 private static boolean tryUntilTimeout(Duration timeout, AssertionSupplier assertOnce) {
 long timeoutMillis = timeout.toMillis();
 long startMillis = System.currentTimeMillis();
 while (System.currentTimeMillis() - startMillis &lt; timeoutMillis) {
 try {
 if (assertOnce.get()) {
 return true;
 }
 } catch (Throwable ex) {
 throwAsUncheckedException(ex);
 }
 }
 return false;
 }

 private static void buildAndThrowAssertionFailure(Duration timeout, Supplier&lt;String&gt; messageSupplier) {
 AssertionFailureBuilder.assertionFailure()
 .message(messageSupplier)
 .reason("execution exceeded timeout of " + timeout.toMillis() + " ms")
 .buildAndThrow();
 }

 private AssertUntilTimeout() {
 /* no-op */
 }
}</code></pre>
<h2 id="단순해진-테스트-코드">단순해진 테스트 코드</h2>
이제 직접 만든 라이브러리를 활용하면 테스트 코드가 다음과 같이 심플해 집니다. 테스트 케이스 마다 달라지는 요소만 콜백으로 라이브러리에게 전달되고, 공통된 처리는 라이브러리가 위임받아 수행하기 때문입니다. 
<pre><code>@Test
void status_reflects_commanded_value_library() {
 // 1. When - 상태 변경 명령 전송
 target.send(new ChangeCommand(100));

 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 assertUntilTimeout(ofMillis(2000), // timeout
 () -&gt; target.readStatus() == 100, // assertOnce
 () -&gt; "status : " + target.readStatus() // message on failure
 );
}</code></pre>
<h2 id="바퀴를-재발명한-건가-junit">바퀴를 재발명한 건가? (JUnit)</h2>
그렇게 얼마 동안 직접 개발한 라이브러리로 테스트 코드를 쉽게 작성할 수 있었습니다. 그런데 어느날 우연히 <a href="https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#verification_timeout">Mockito 레퍼런스 페이지</a>를 읽는데 timeout을 활용한 검증 기능이 눈에 띄었습니다. 
<img src="https://velog.velcdn.com/images/joosing/post/aa1510ee-70fb-4342-8606-7c781cdaddb7/image.png">
조금 당황스러웠습니다. Mockito에 이런 기능이 있다면 JUnit에도 당연히 기능이 존재할 거라 예상할 수 있었습니다. 아니나 다를까 JUnit에서도 Assertions 클래스에 assertTimeout() 이라는 타임아웃 기반 검증 API를 제공하고 있었습니다. 그래서 바퀴를 재발명한 어리석은 일을 했다며 머리를 한대 쥐어박고 JUnit API를 사용하도록 테스트 코드를 바꾸어 보았습니다. 
<pre><code>@Test
void status_reflects_commanded_value_junit() {
 // 1. When - 상태 변경 명령 전송
 target.send(new ChangeCommand(100));

 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 assertTimeout(ofMillis(2000), // timeout
 () -&gt; {
 while (target.readStatus() != 100) { // assert
 Thread.sleep(100);
 }
 }, () -&gt; "status : " + target.readStatus() // message on failure
 );
}</code></pre>
그런데 다행히도(?) 제가 만든 것과 JUnit이 제공하는 것에는 작은 차이점이 있었습니다. 제가 만든 라이브러리는 Assertion을 위한 조건을 체크하는 람다식을 입력 받고 실행을 반복하는 책임은 라이브러리가 가지고 있습니다. 반면에 JUnit의 API는 사용자가 직접 반복하는 책임을 가지고 코드를 작성해야 했습니다. 사소한 차이지만 사용자가 반복의 책임을 질 필요가 없겠다고 생각했습니다. 문득 JUnit이라는 유익한 오프소스 프로젝트에 기능을 제안해 볼 좋은 기회라 생각되어 이때다 싶어 JUnit GitHub에 가서 <a href="https://github.com/junit-team/junit5/issues/3152">이슈</a>를 남겼습니다. 
<h2 id="놀라운-도메인-특화-언어-awaitility">놀라운 도메인 특화 언어 (Awaitility)</h2>
유용한 오픈소스 프로젝트에 업무를 통해 만든 코드를 기여할 수 있다면 얼마나 좋은 일일까요! 기쁜 마음으로 정성껏 이슈를 작성해서 남겼는데 JUnit 메인테이너 중 한 사람이 곧 답변을 달아주었습니다. 한 마디로 Awaitility 라는 기술을 사용해 봤냐는 겁니다. 
<img src="https://velog.velcdn.com/images/joosing/post/83fe9e21-27b8-4749-9516-c2cc01c72c11/image.png">
저는 처음 듣는 기술이었는데, 뭔가 해서 가봤습니다. 그리고 Readme를 읽기 시작하는데 심상치 않은 도구임을 직감했습니다.
<img src="https://velog.velcdn.com/images/joosing/post/63845e18-ae20-4bb5-a85d-9f15b44f7727/image.png">
결론적으로 <a href="https://github.com/awaitility/awaitility/wiki/Usage">Awaitility Usage Guide</a>를 통해 쉽게 라이브러리 사용법을 학습할 수 있었고 제가 원하는 모든 기능이 매우 유연하게 제공되고 있었습니다. Awaitility는 스스로를 라이브러리라 소개하지 않고 DSL(Domain-specific language)이라고 소개하는데 작성된 예시 코드를 보면 정말 하나의 테스트 도메인 언어 같은 느낌이 듭니다. 아래는 기존에 작성된 예제를 Awaitility를 사용하도록 바꿔본 코드입니다. 훌륭하지 않나요? 정말 놀랍고 완벽했습니다. 여러분도 비동기 시스템을 개발하고 테스트하신다면 Awaitility 도메인 언어를 한 번 활용해 보시길 권해 드립니다.
<pre><code>@Test
void status_reflects_commanded_value_awaitility() {
 // 1. When - 상태 변경 명령 전송
 target.send(new ChangeCommand(100));

 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 with().conditionEvaluationListener(condition -&gt; log.info("status on failure : {}", target.readStatus())) // 테스트 조건 확인 시, 상태 값을 출력합니다
 .await() // 기다립니다 
 .atMost(500, MILLISECONDS) // 500 msec 동안
 .pollInterval(ofMillis(100)) // 100 msec 간격으로 
 .until(() -&gt; target.readStatus() == 100); // 다음 조건을 통과할 때까지
}</code></pre></div></div>

Joo's Work

JooSing

이 글에서는 비동기 시스템의 테스트 코드를 개선해 나간 과정을 소개합니다. 이 과정의 끝에는 Awaitility 라는, 스스로를 테스트 라이브러리가 아닌 DSL(Domain-specific language)이라 소개하는 기술이 있는데 Awaitility를 사용해서 아주 읽기 좋고, 간결한 테스트 코드를 작성할 수 있었습니다. 
비동기 시스템 특징
우리가 API 시스템에 어떤 변경 명령을 보내고, 응답을 받는 상황을 생각해 봅시다. 동기(Sync) 시스템에서 응답은 “요청에 대한 처리가 완료 되었어” 라는 의미를 담고 있습니다. 반면 비동기(Async) 시스템에서 응답은 “요청을 잘 받았고, 단지 처리를 시작 했어” 라는 다른 의미를 담고 있습니다. 그렇기 때문에 비동기 시스템에서는 명령에 대한 응답을 받았다고 해서 변경이 완료되었다고 가정할 수 없고, 추후 어떤 방법으로든 결과를 체크해야하는 구조적인 특징을 가집니다.
비동기 시스템 테스트 코드
따라서 우리가 비동기 시스템의 상태를 변경하는 동작을 테스트할 때에는 동기적인 코드를 테스트할 때와는 다른 패턴의 코드를 작성하게 됩니다. 
동기식 테스트
동기식 시스템에서는 상태변경 명령을 보내고 간단하게 즉시 결과를 확인할 수 있습니다. 
@Test
void status_reflects_commanded_value() {
 // 1. When - 상태 변경 명령 전송
 target.send(new ChangeCommand(100));
 // 2. Then - 상태 변경 여부 확인
 assertEquals(100, target.readStatus());
}
비동기식 테스트
반면에 비동기식 시스템에서는 상태 변경 명령을 보낸 후, 일정 시간 동안 시스템이 원하는 상태로 변경 되었는지 반복해서 체크해야 합니다. 
API 시스템에서 이벤트 리스너를 등록하고 처리 완료 알람을 주는 방법을 지원한다면 테스트가 더 간단해 질 수 있습니다. 그러나 그렇지 않은 경우 아래와 같이 직접 반복적으로 상태를 체크하는 폴링(Polling) 방식을 사용해야 합니다. 이 글은 폴링해야 하는 비동기 시스템을 테스트하는 예입니다.
@Test
void status_reflects_commanded_value() {
 // 1. When - 상태 변경 명령 전송
 target.send(new ChangeCommand(100));
 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 long startMillis = System.currentTimeMillis();
 while (System.currentTimeMillis() - startMillis < 2000) {
 if (target.readStatus() == 100) {
 // 성공
 return;
 }
 }
 // 3. (실패 시) 실패 판정에 사용된 값 출력
 log.info("status : {}", target.readStatus());
 fail();
}
라이브러리 직접 만들기
위의 코드를 잠시 살펴보면 앞으로 중복될 코드들이 너무 많습니다. 비동기적인 상태 변경을 반복 체크하는 코드 조각(주석 2)에서 “target.readStatus() == 100” 부분 외에는 매 번 반복될 것이고, 실패 판정에 사용된 값을 출력하는 코드 조각(주석 3)에서도 “status : {}", target.readStatus()” 상태 문자열 외에는 모두 중복될 것입니다. 그래서 변경되지 않는 부분은 템플릿으로 만들고, 변경되는 부분은 콜백으로 받아 처리하는 자체 라이브러리를 만들었습니다. (아래 코드는 라이브러리의 초기 모습은 아니고, 최근에 JUnit의 구현을 보고 유사한 스타일로 재구성한 모습입니다)
public class AssertUntilTimeout {
 /**
 * 제한시간(timeout) 동안 특정 조건을 만족(assertOnce)하는지 반복 확인합니다. 조건 만족 시 즉시 실행을 반환하고, 타임아웃 시 테스트
 * 실패를 알리는 예외를 던집니다.
 *
 * @param timeout 제한시간
 * @param assertOnce 한 번 조건을 확인하는 함수
 * @param messageSupplier 실패 메시지 생성 함수
 */
 public static void assertUntilTimeout(Duration timeout, AssertionSupplier assertOnce, Supplier<String> messageSupplier) {
 if (!tryUntilTimeout(timeout, assertOnce)) {
 buildAndThrowAssertionFailure(timeout, messageSupplier);
 }
 }
 private static boolean tryUntilTimeout(Duration timeout, AssertionSupplier assertOnce) {
 long timeoutMillis = timeout.toMillis();
 long startMillis = System.currentTimeMillis();
 while (System.currentTimeMillis() - startMillis < timeoutMillis) {
 try {
 if (assertOnce.get()) {
 return true;
 }
 } catch (Throwable ex) {
 throwAsUncheckedException(ex);
 }
 }
 return false;
 }
 private static void buildAndThrowAssertionFailure(Duration timeout, Supplier<String> messageSupplier) {
 AssertionFailureBuilder.assertionFailure()
 .message(messageSupplier)
 .reason("execution exceeded timeout of " + timeout.toMillis() + " ms")
 .buildAndThrow();
 }
 private AssertUntilTimeout() {
 /* no-op */
 }
}
단순해진 테스트 코드
이제 직접 만든 라이브러리를 활용하면 테스트 코드가 다음과 같이 심플해 집니다. 테스트 케이스 마다 달라지는 요소만 콜백으로 라이브러리에게 전달되고, 공통된 처리는 라이브러리가 위임받아 수행하기 때문입니다. 
@Test
void status_reflects_commanded_value_library() {
 // 1. When - 상태 변경 명령 전송
 target.send(new ChangeCommand(100));
 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 assertUntilTimeout(ofMillis(2000), // timeout
 () -> target.readStatus() == 100, // assertOnce
 () -> "status : " + target.readStatus() // message on failure
 );
}
바퀴를 재발명한 건가? (JUnit)
그렇게 얼마 동안 직접 개발한 라이브러리로 테스트 코드를 쉽게 작성할 수 있었습니다. 그런데 어느날 우연히 Mockito 레퍼런스 페이지를 읽는데 timeout을 활용한 검증 기능이 눈에 띄었습니다. 
조금 당황스러웠습니다. Mockito에 이런 기능이 있다면 JUnit에도 당연히 기능이 존재할 거라 예상할 수 있었습니다. 아니나 다를까 JUnit에서도 Assertions 클래스에 assertTimeout() 이라는 타임아웃 기반 검증 API를 제공하고 있었습니다. 그래서 바퀴를 재발명한 어리석은 일을 했다며 머리를 한대 쥐어박고 JUnit API를 사용하도록 테스트 코드를 바꾸어 보았습니다. 
@Test
void status_reflects_commanded_value_junit() {
 // 1. When - 상태 변경 명령 전송
 target.send(new ChangeCommand(100));
 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 assertTimeout(ofMillis(2000), // timeout
 () -> {
 while (target.readStatus() != 100) { // assert
 Thread.sleep(100);
 }
 }, () -> "status : " + target.readStatus() // message on failure
 );
}
그런데 다행히도(?) 제가 만든 것과 JUnit이 제공하는 것에는 작은 차이점이 있었습니다. 제가 만든 라이브러리는 Assertion을 위한 조건을 체크하는 람다식을 입력 받고 실행을 반복하는 책임은 라이브러리가 가지고 있습니다. 반면에 JUnit의 API는 사용자가 직접 반복하는 책임을 가지고 코드를 작성해야 했습니다. 사소한 차이지만 사용자가 반복의 책임을 질 필요가 없겠다고 생각했습니다. 문득 JUnit이라는 유익한 오프소스 프로젝트에 기능을 제안해 볼 좋은 기회라 생각되어 이때다 싶어 JUnit GitHub에 가서 이슈를 남겼습니다. 
놀라운 도메인 특화 언어 (Awaitility)
유용한 오픈소스 프로젝트에 업무를 통해 만든 코드를 기여할 수 있다면 얼마나 좋은 일일까요! 기쁜 마음으로 정성껏 이슈를 작성해서 남겼는데 JUnit 메인테이너 중 한 사람이 곧 답변을 달아주었습니다. 한 마디로 Awaitility 라는 기술을 사용해 봤냐는 겁니다. 
저는 처음 듣는 기술이었는데, 뭔가 해서 가봤습니다. 그리고 Readme를 읽기 시작하는데 심상치 않은 도구임을 직감했습니다.
결론적으로 Awaitility Usage Guide를 통해 쉽게 라이브러리 사용법을 학습할 수 있었고 제가 원하는 모든 기능이 매우 유연하게 제공되고 있었습니다. Awaitility는 스스로를 라이브러리라 소개하지 않고 DSL(Domain-specific language)이라고 소개하는데 작성된 예시 코드를 보면 정말 하나의 테스트 도메인 언어 같은 느낌이 듭니다. 아래는 기존에 작성된 예제를 Awaitility를 사용하도록 바꿔본 코드입니다. 훌륭하지 않나요? 정말 놀랍고 완벽했습니다. 여러분도 비동기 시스템을 개발하고 테스트하신다면 Awaitility 도메인 언어를 한 번 활용해 보시길 권해 드립니다.
@Test
void status_reflects_commanded_value_awaitility() {
 // 1. When - 상태 변경 명령 전송
 target.send(new ChangeCommand(100));
 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 with().conditionEvaluationListener(condition -> log.info("status on failure : {}", target.readStatus())) // 테스트 조건 확인 시, 상태 값을 출력합니다
 .await() // 기다립니다 
 .atMost(500, MILLISECONDS) // 500 msec 동안
 .pollInterval(ofMillis(100)) // 100 msec 간격으로 
 .until(() -> target.readStatus() == 100); // 다음 조건을 통과할 때까지
}

비동기 시스템 테스트 코드 개선기 (until Awaitility)

댓글