<div id="readability-page-1" class="page"><div><h2 id="이번-주에-한-것">이번 주에 한 것</h2>
<p><strong>간단하게 말하면, 테스트를 작성했다.</strong></p>
<ul>
<li>유닛 테스트 작성</li>
<li>계층형 테스트 작성<ul>
<li>준비, 시작, 단언 (AAA, arrange-act-assert) 규약을 약간 변형했다.</li>
<li>Given, When, Then 에서 Describe, Context, It 이 된다.</li>
</ul></li>
<li>Controller 에 대한 Mock 테스트 작성<ul>
<li><code>@WebMvcTest</code> 를 이용한 웹 레이어 테스트</li>
<li><code>@AutoConfigureMockMvc</code> 를 이용한 통합 테스트</li>
</ul></li>
<li><a href="https://jake-seo-dev.tistory.com/64">Test Double 에 대한 학습</a></li>
<li>Mockito 활용법에 대한 학습</li>
</ul>
<h3 id="배운-것-1-테스트-코드조차-코드의-퀄리티가-중요하다">배운 것 1: 테스트 코드조차 코드의 퀄리티가 중요하다.</h3>
<ul>
<li>의도를 명확히 드러내기 위해서 JUnit5 가 기본적으로 제공하는 단정문(Assertion)이 아닌 AssertJ 라이브러리를 따로 설치해서 이용했다.</li>
<li>고정적으로 사용되는 데이터를 Fixture 라는 형태로 만들어두어 재사용했다.</li>
<li>그 외에도, 비슷한 메서드가 매 테스트마다 쓰이는 경우엔 상속 등을 이용할 수 있었고 일반 코드 퀄리티를 지키듯 테스트 코드도 코드 퀄리티를 지켜나갔다.</li>
</ul>
<h3 id="배운-것-2-테스트-코드는-항상-꼼꼼하게-작성해야-한다">배운 것 2: 테스트 코드는 항상 꼼꼼하게 작성해야 한다.</h3>
<ul>
<li>특히 정상 작동하는 것 외에 정상작동하지 않을만한 것에 집중해보자.<ul>
<li>경계값, 예상치 못한 입력값, 쉽게 생각할 수 있는 틀린 값 등을 테스트해보자.</li>
</ul></li>
</ul>
<h3 id="배운-것-3-테스트-대상-코드를-격리해보자">배운 것 3: 테스트 대상 코드를 격리해보자.</h3>
<ul>
<li>스프링의 웹 아키텍처에서 가장 널리 쓰이는 레이어로는 <code>Controller</code>, <code>Service</code>, <code>Repository</code> 가 있다. 이를 레이어 별로 나눠서 잘 테스트할 수 있다면, 해당 레이어는 다른 레이어의 영역에 침범하지 않는 것으로 간주할 수 있다.</li>
<li><code>Mock</code> 을 적극 활용하면 테스트 대상 코드를 격리할 수 있다.<ul>
<li>단, <code>Mock</code> 을 이용한 격리는 상호작용하는 다른 객체가 올바르게 값을 준다는 가정 하에 이뤄지는 테스트이니 꼭 통합 테스트로 다시한번 검증해보자.</li>
</ul></li>
</ul>
<h3 id="배운-것-4-mock-은-왜-사용하는가">배운 것 4: Mock 은 왜 사용하는가?</h3>
<ul>
<li>객체간의 관계를 알 수 있다.</li>
<li>"Mocking 이 너무 어렵다는 것은 =&gt; 결합도가 높다. =&gt; 설계 개선이 필요하다."</li>
</ul>
<h2 id="과제-풀이-영상-리뷰">과제 풀이 영상 리뷰</h2>
<h3 id="과제를-하며-배운-것-1-mock-을-적극-활용하여-코드-격리를-한다">과제를 하며 배운 것 1: Mock 을 적극 활용하여 코드 격리를 한다.</h3>
<ul>
<li>Mockito 에는 <code>spy()</code>, <code>given()</code>, <code>verify()</code>, <code>eq()</code>, <code>any()</code> 등 어떤 객체든 흉내낼 수 있는 다양한 메서드를 제공한다.</li>
<li>풀이 영상에서는 이를 적극 활용하여 각각의 레이어를 나눠 테스트했다.<br>
1) <code>Service</code> 레이어에서는 Mocking 없이 꼼꼼한 유닛 테스트로 동작을 보장했다.<br>
2) <code>Controller</code> 레이어에서는 <code>Controller</code> 에 정상적인 <code>Service</code> 가 주입되어 있다고 가정하에 <code>Controller</code> 객체가 올바르게 동작하는지 테스트했다.<br>
3) <code>Web</code> 레이어에서는 <code>mockMvc</code>를 이용해서 실제로 HTTP 요청을 하는 것처럼 테스트를 해보았다.</li>
</ul>
<h2 id="코드-리뷰에서-지적받은-것">코드 리뷰에서 지적받은 것</h2>
<h3 id="parameterizedtest-고려의-필요성"><code>ParameterizedTest</code> 고려의 필요성</h3>
<p><img src="https://velog.velcdn.com/images/jakeseo_me/post/b855f237-3662-4384-922e-b22f26526f9d/image.png"></p>
<p><code>ParameterizedTest</code> 의 경우, 아직 한번도 사용해본 적이 없는데, 특정한 파라미터가 오면 이뤄지는 동작이라는 것을 더 강조하고 싶을 때 사용해보면 괜찮을 것 같다.</p>
<p>위에서는 <code>task.setTitle()</code> 에 오는 파라미터에 따라 달라지는 동작을 표현했으면 더 좋았을 것 같다.</p>
<h3 id="테스트에서-사용된-애매한-단어-잘못된">테스트에서 사용된 애매한 단어 '잘못된'</h3>
<p><img src="https://velog.velcdn.com/images/jakeseo_me/post/e64631dc-bb0b-4e9e-a145-0b716a4989b3/image.png"></p>
<p><code>잘못된</code> 이라는 단어는 구체적이지 않다. <code>존재하지 않는 ID</code>, <code>형식에 맞지 않는 ID</code> 등으로 테스트의 목적을 작성할 때는 더욱 구체적으로 작성해보자.</p>
<h3 id="너무-긴-변수명은-쓸데-없는-주의를-끈다">너무 긴 변수명은 쓸데 없는 주의를 끈다.</h3>
<p><img src="https://velog.velcdn.com/images/jakeseo_me/post/34029351-0d89-4ba2-8e89-9e30efdb7435/image.png"></p>
<p>위에서 <code>taskArgumentWithTitle</code> 은 사실 딱히 길게 쓸 이유는 없는 변수명이다. 너무 길게 지어서 쓸데 없는 주의를 끌지 말자.</p>
<h2 id="내가-느낀-것">내가 느낀 것</h2>
<ul>
<li>테스트를 이용해 코드를 빠르게 작성하면, 쉽게 리팩토링할 수 있다는 장점이 있다.</li>
<li>테스트 코드에서도 코드의 퀄리티를 지키려 노력해야 한다.</li>
<li>테스트 영역을 격리하여 관심사의 분리를 확실히 하고, 어떤 영역에서 문제가 발생했는지 더 확실히 알아보자.</li>
</ul>
<h2 id="여전히-남은-의문사항">여전히 남은 의문사항</h2>
<ul>
<li>모든 메서드에 대해 테스트를 만드는 것이 바람직한가?<ul>
<li>가끔은 시간낭비가 아닐까? 일단은 학습 단계이니 작성해보자.</li>
</ul></li>
<li><code>@Service</code> 를 테스트할 때 통합 테스트와 <code>Mock</code> 테스트 어떤 것을 우선시 해야하는가?<ul>
<li>분리 테스트: <code>@WebMvcTest</code> 를 사용하고 <code>Service</code> 에 대해 <code>@MockBean</code> 을 사용하는 것</li>
<li>통합 테스트: <code>@SpringBootTest</code> 와 <code>@AutoConfigureMockMvc</code> 를 사용하는 것</li>
</ul></li>
</ul></div></div>

jakeseo-javascript.js 🔨

이번 주에 한 것
간단하게 말하면, 테스트를 작성했다.
유닛 테스트 작성
계층형 테스트 작성
준비, 시작, 단언 (AAA, arrange-act-assert) 규약을 약간 변형했다.
Given, When, Then 에서 Describe, Context, It 이 된다.
Controller 에 대한 Mock 테스트 작성
@WebMvcTest 를 이용한 웹 레이어 테스트
@AutoConfigureMockMvc 를 이용한 통합 테스트
Test Double 에 대한 학습
Mockito 활용법에 대한 학습
배운 것 1: 테스트 코드조차 코드의 퀄리티가 중요하다.
의도를 명확히 드러내기 위해서 JUnit5 가 기본적으로 제공하는 단정문(Assertion)이 아닌 AssertJ 라이브러리를 따로 설치해서 이용했다.
고정적으로 사용되는 데이터를 Fixture 라는 형태로 만들어두어 재사용했다.
그 외에도, 비슷한 메서드가 매 테스트마다 쓰이는 경우엔 상속 등을 이용할 수 있었고 일반 코드 퀄리티를 지키듯 테스트 코드도 코드 퀄리티를 지켜나갔다.
배운 것 2: 테스트 코드는 항상 꼼꼼하게 작성해야 한다.
특히 정상 작동하는 것 외에 정상작동하지 않을만한 것에 집중해보자.
경계값, 예상치 못한 입력값, 쉽게 생각할 수 있는 틀린 값 등을 테스트해보자.
배운 것 3: 테스트 대상 코드를 격리해보자.
스프링의 웹 아키텍처에서 가장 널리 쓰이는 레이어로는 Controller, Service, Repository 가 있다. 이를 레이어 별로 나눠서 잘 테스트할 수 있다면, 해당 레이어는 다른 레이어의 영역에 침범하지 않는 것으로 간주할 수 있다.
Mock 을 적극 활용하면 테스트 대상 코드를 격리할 수 있다.
단, Mock 을 이용한 격리는 상호작용하는 다른 객체가 올바르게 값을 준다는 가정 하에 이뤄지는 테스트이니 꼭 통합 테스트로 다시한번 검증해보자.
배운 것 4: Mock 은 왜 사용하는가?
객체간의 관계를 알 수 있다.
"Mocking 이 너무 어렵다는 것은 => 결합도가 높다. => 설계 개선이 필요하다."
과제 풀이 영상 리뷰
과제를 하며 배운 것 1: Mock 을 적극 활용하여 코드 격리를 한다.
Mockito 에는 spy(), given(), verify(), eq(), any() 등 어떤 객체든 흉내낼 수 있는 다양한 메서드를 제공한다.
풀이 영상에서는 이를 적극 활용하여 각각의 레이어를 나눠 테스트했다.
1) Service 레이어에서는 Mocking 없이 꼼꼼한 유닛 테스트로 동작을 보장했다.
2) Controller 레이어에서는 Controller 에 정상적인 Service 가 주입되어 있다고 가정하에 Controller 객체가 올바르게 동작하는지 테스트했다.
3) Web 레이어에서는 mockMvc를 이용해서 실제로 HTTP 요청을 하는 것처럼 테스트를 해보았다.
코드 리뷰에서 지적받은 것
ParameterizedTest 고려의 필요성
ParameterizedTest 의 경우, 아직 한번도 사용해본 적이 없는데, 특정한 파라미터가 오면 이뤄지는 동작이라는 것을 더 강조하고 싶을 때 사용해보면 괜찮을 것 같다.
위에서는 task.setTitle() 에 오는 파라미터에 따라 달라지는 동작을 표현했으면 더 좋았을 것 같다.
테스트에서 사용된 애매한 단어 '잘못된'
잘못된 이라는 단어는 구체적이지 않다. 존재하지 않는 ID, 형식에 맞지 않는 ID 등으로 테스트의 목적을 작성할 때는 더욱 구체적으로 작성해보자.
너무 긴 변수명은 쓸데 없는 주의를 끈다.
위에서 taskArgumentWithTitle 은 사실 딱히 길게 쓸 이유는 없는 변수명이다. 너무 길게 지어서 쓸데 없는 주의를 끌지 말자.
내가 느낀 것
테스트를 이용해 코드를 빠르게 작성하면, 쉽게 리팩토링할 수 있다는 장점이 있다.
테스트 코드에서도 코드의 퀄리티를 지키려 노력해야 한다.
테스트 영역을 격리하여 관심사의 분리를 확실히 하고, 어떤 영역에서 문제가 발생했는지 더 확실히 알아보자.
여전히 남은 의문사항
모든 메서드에 대해 테스트를 만드는 것이 바람직한가?
가끔은 시간낭비가 아닐까? 일단은 학습 단계이니 작성해보자.
@Service 를 테스트할 때 통합 테스트와 Mock 테스트 어떤 것을 우선시 해야하는가?
분리 테스트: @WebMvcTest 를 사용하고 Service 에 대해 @MockBean 을 사용하는 것
통합 테스트: @SpringBootTest 와 @AutoConfigureMockMvc 를 사용하는 것

코드숨 스프링 편 3주차 회고: 테스트

댓글