<div id="readability-page-1" class="page"><div id="entry-view">
      
      <main>
        <section>
          <h2>테스트코드 작성 하시나요?</h2>
          <div>
            <article id="mainContent">
              
              <p><cite>anyjava</cite>
                <span> 2023. 11. 13. 08:00</span>
              </p>
                          
            
                <div>
                                <figure data-ke-mobilestyle="widthOrigin" data-filename="ferenc-almasi-EWLHA4T-mso-unsplash.jpg" data-origin-width="5184" data-origin-height="3456">
    <span data-url="https://blog.kakaocdn.net/dn/biBQvE/btsAeB40HYf/sHiMDi7fwAkjjoY6vykwz0/img.jpg" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/biBQvE/btsAeB40HYf/sHiMDi7fwAkjjoY6vykwz0/img.jpg" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="ferenc-almasi-EWLHA4T-mso-unsplash.jpg" data-origin-width="5184" data-origin-height="3456">
    </span>
    
</figure>
<p data-ke-size="size16">사진: <a href="https://unsplash.com/ko/%EC%82%AC%EC%A7%84/%EC%BD%94%EB%93%9C-%EB%B2%88%ED%98%B8%EA%B0%80-%EC%9E%88%EB%8A%94-%EC%BB%B4%ED%93%A8%ED%84%B0-%ED%99%94%EB%A9%B4-%ED%81%B4%EB%A1%9C%EC%A6%88%EC%97%85-EWLHA4T-mso?utm_content=creditCopyText&amp;utm_medium=referral&amp;utm_source=unsplash">Unsplash</a>의<a href="https://unsplash.com/ko/@flowforfrank?utm_content=creditCopyText&amp;utm_medium=referral&amp;utm_source=unsplash">Ferenc Almasi</a></p>


<div data-ke-size="size16"><p>얼마&nbsp;전&nbsp;모임에서&nbsp;만난&nbsp;후배&nbsp;개발자가&nbsp;면접&nbsp;경험을&nbsp;공유했다.&nbsp;'면접관이&nbsp;테스트&nbsp;코드&nbsp;작성&nbsp;여부를&nbsp;물었다'라고&nbsp;했다.&nbsp;나&nbsp;역시&nbsp;면접에서&nbsp;이를&nbsp;중요하게&nbsp;여긴다.</p><p>면접에서&nbsp;나는&nbsp;테스트&nbsp;코드&nbsp;작성의&nbsp;이유를&nbsp;반드시&nbsp;질문한다.&nbsp;단순히&nbsp;테스트를&nbsp;어떻게&nbsp;작성에&nbsp;대한&nbsp;하드스킬에&nbsp;대한&nbsp;질문의&nbsp;의도가&nbsp;아니다.&nbsp;테스트를&nbsp;정말&nbsp;작성을&nbsp;한다면&nbsp;경험을&nbsp;기반으로 한&nbsp;필요성에&nbsp;대해서&nbsp;설명할&nbsp;수&nbsp;있다고&nbsp;생각하기&nbsp;때문이다.&nbsp;<br>실제 업무에서 테스트코드 작성을 하게 된다면 업무 생상성뿐만이 아니라 좋은 코드 설계도 가능하다고 생각하기 때문이다.&nbsp;&nbsp;왜&nbsp;&nbsp;그렇게 생각하는지를 좀 정리를 해보려고 한다.</p><p>첫 번째&nbsp;이유는&nbsp;빠른&nbsp;피드백이다.&nbsp;예를&nbsp;들어&nbsp;회원가입&nbsp;API를&nbsp;만드는&nbsp;Task&nbsp;가&nbsp;있다고&nbsp;하자.&nbsp;이메일&nbsp;형식을&nbsp;검증하는&nbsp;요구사항이&nbsp;있는데,&nbsp;POST&nbsp;/users&nbsp;API를&nbsp;작성하면서&nbsp;회원가입 시&nbsp;이메일을&nbsp;유효성&nbsp;검사기능을&nbsp;개발자&nbsp;수준에서&nbsp;테스트를&nbsp;해야&nbsp;할&nbsp;것이다.&nbsp;테스트&nbsp;코드가&nbsp;없다면&nbsp;코드를&nbsp;작성하고&nbsp;API를&nbsp;호출해서&nbsp;테스트하고,&nbsp;버그가&nbsp;있다며&nbsp;다시&nbsp;수정하고&nbsp;API&nbsp;호출&nbsp;테스트&nbsp;해보고&nbsp;이&nbsp;사이클을&nbsp;계속적으로&nbsp;반복하게&nbsp;된다.&nbsp;아무리&nbsp;빨라도&nbsp;5초&nbsp;정도&nbsp;소요가&nbsp;된다고&nbsp;하자.&nbsp;이를&nbsp;테스트코드를&nbsp;이용한다면&nbsp;처음&nbsp;작성이&nbsp;시간이&nbsp;걸리겠지만,&nbsp;처음&nbsp;이후에는&nbsp;1s&nbsp;도&nbsp;안 걸릴&nbsp;것이다.&nbsp;만약&nbsp;이런&nbsp;상황이&nbsp;누적된다면&nbsp;생산성에&nbsp;많은&nbsp;기여를&nbsp;할 것이다.</p><p>두 번째는&nbsp;복잡한&nbsp;요구사항을&nbsp;표현할&nbsp;수&nbsp;있다.&nbsp;&nbsp;프로그래밍을&nbsp;하다가&nbsp;if&nbsp;문을&nbsp;통해서&nbsp;로직의&nbsp;분기를&nbsp;해야 하는&nbsp;상황이&nbsp;있다.&nbsp;그런&nbsp;상황은&nbsp;십중팔구&nbsp;비즈니스&nbsp;요구사항이&nbsp;들어간다.&nbsp;&nbsp;“최소주문&nbsp;금액보다&nbsp;음식가격이&nbsp;낮다면&nbsp;주문&nbsp;실패를&nbsp;한다.”라는&nbsp;요구사항을&nbsp;위해&nbsp;분기문을&nbsp;사용할&nbsp;수밖에&nbsp;없다.&nbsp;&nbsp;이런&nbsp;의도를&nbsp;테스트코드로&nbsp;작성을&nbsp;하고&nbsp;누군가가&nbsp;해당&nbsp;코드를&nbsp;리팩토링&nbsp;하다가&nbsp;지우는&nbsp;버그도&nbsp;예방을&nbsp;할&nbsp;수가&nbsp;있다.&nbsp;&nbsp;그래서&nbsp;나는&nbsp;팀에서&nbsp;Branch(Condition)&nbsp;Coverage를&nbsp;관리를&nbsp;한다.</p><p>세 번째는&nbsp;자유로운&nbsp;리팩토링이&nbsp;가능하다.&nbsp;&nbsp;테스트&nbsp;코드를&nbsp;작성하며&nbsp;개발하는&nbsp;도중,&nbsp;한&nbsp;선배&nbsp;개발자가&nbsp;프로젝트의&nbsp;패키지&nbsp;구조를&nbsp;대대적으로&nbsp;변경한&nbsp;적이&nbsp;있다.&nbsp;당연히&nbsp;내가&nbsp;작성한&nbsp;코드에도&nbsp;영향이&nbsp;있었고,&nbsp;처음에는&nbsp;큰&nbsp;변화에&nbsp;대한&nbsp;두려움이&nbsp;있었다.&nbsp;실제를&nbsp;conflict를&nbsp;스스로&nbsp;해결해&nbsp;보았는데,&nbsp;테스트코드&nbsp;때문에&nbsp;오히려&nbsp;심리적&nbsp;안전하다는&nbsp;생각이&nbsp;들었다.&nbsp;&nbsp;그래서&nbsp;리팩토링의&nbsp;첫 단계는&nbsp;테스트코드라고&nbsp;말하는&nbsp;것이다.&nbsp;</p><p>네 번째는&nbsp;설계의&nbsp;개선이&nbsp;가능하다는&nbsp;것이다.&nbsp;테스트코드를&nbsp;작성을&nbsp;쉽게&nbsp;하기 위해서는&nbsp;유연한&nbsp;의존성이&nbsp;필수적이다.&nbsp;자연스레&nbsp;코어&nbsp;비즈니스로직과&nbsp;세부사항을&nbsp;분리를&nbsp;하게&nbsp;된다.&nbsp;단위&nbsp;테스트&nbsp;대상&nbsp;클래스와&nbsp;협력하는&nbsp;클래스 간의&nbsp;의존성이라&nbsp;메시지&nbsp;규약도&nbsp;고려를&nbsp;하게&nbsp;된다.</p><p>아주&nbsp;가볍게&nbsp;내가&nbsp;생각하는&nbsp;이유들을&nbsp;적어&nbsp;보았다.&nbsp;동의하는&nbsp;부분도&nbsp;있을 테고&nbsp;동의하지&nbsp;않는&nbsp;부분도&nbsp;있을 것이다.&nbsp;(다양한&nbsp;의견&nbsp;환영합니다.)&nbsp;나도&nbsp;이 글을&nbsp;쓰면서&nbsp;이&nbsp;글을&nbsp;읽으시는&nbsp;분들에게&nbsp;빠르게&nbsp;피드백을&nbsp;받고자&nbsp;하는&nbsp;목적도&nbsp;있기&nbsp;때문이다.&nbsp;</p><p>빠른&nbsp;피드백,&nbsp;유연한&nbsp;의존성,&nbsp;그리고&nbsp;리팩토링의&nbsp;용이성을&nbsp;갖추어&nbsp;나가다&nbsp;보면&nbsp;어제&nbsp;보다&nbsp;나은&nbsp;코드를&nbsp;만들기&nbsp;위한&nbsp;프로덕트의&nbsp;기본&nbsp;바탕이 될&nbsp;수&nbsp;있지&nbsp;않을까&nbsp;생각한다.&nbsp;&nbsp;다음에는&nbsp;좀&nbsp;더&nbsp;구체적인&nbsp;사례로&nbsp;테스트&nbsp;코드&nbsp;작성을&nbsp;어떻게&nbsp;할&nbsp;수&nbsp;소개해&nbsp;보도록&nbsp;하겠다.</p></div>
            
            
                </div>
              
            </article>
            
              
            
            
            
            
            
            
            
              
              
            
          </div>
        </section>
      </main>
    </div></div>

또라이개발자

Son Hyeon Tae

사진: Unsplash의Ferenc Almasi
 
 
얼마 전 모임에서 만난 후배 개발자가 면접 경험을 공유했다. '면접관이 테스트 코드 작성 여부를 물었다'라고 했다. 나 역시 면접에서 이를 중요하게 여긴다.
면접에서 나는 테스트 코드 작성의 이유를 반드시 질문한다. 단순히 테스트를 어떻게 작성에 대한 하드스킬에 대한 질문의 의도가 아니다. 테스트를 정말 작성을 한다면 경험을 기반으로 한 필요성에 대해서 설명할 수 있다고 생각하기 때문이다. 
실제 업무에서 테스트코드 작성을 하게 된다면 업무 생상성뿐만이 아니라 좋은 코드 설계도 가능하다고 생각하기 때문이다.  왜  그렇게 생각하는지를 좀 정리를 해보려고 한다.
첫 번째 이유는 빠른 피드백이다. 예를 들어 회원가입 API를 만드는 Task 가 있다고 하자. 이메일 형식을 검증하는 요구사항이 있는데, POST /users API를 작성하면서 회원가입 시 이메일을 유효성 검사기능을 개발자 수준에서 테스트를 해야 할 것이다. 테스트 코드가 없다면 코드를 작성하고 API를 호출해서 테스트하고, 버그가 있다며 다시 수정하고 API 호출 테스트 해보고 이 사이클을 계속적으로 반복하게 된다. 아무리 빨라도 5초 정도 소요가 된다고 하자. 이를 테스트코드를 이용한다면 처음 작성이 시간이 걸리겠지만, 처음 이후에는 1s 도 안 걸릴 것이다. 만약 이런 상황이 누적된다면 생산성에 많은 기여를 할 것이다.
두 번째는 복잡한 요구사항을 표현할 수 있다.  프로그래밍을 하다가 if 문을 통해서 로직의 분기를 해야 하는 상황이 있다. 그런 상황은 십중팔구 비즈니스 요구사항이 들어간다.  “최소주문 금액보다 음식가격이 낮다면 주문 실패를 한다.”라는 요구사항을 위해 분기문을 사용할 수밖에 없다.  이런 의도를 테스트코드로 작성을 하고 누군가가 해당 코드를 리팩토링 하다가 지우는 버그도 예방을 할 수가 있다.  그래서 나는 팀에서 Branch(Condition) Coverage를 관리를 한다.
세 번째는 자유로운 리팩토링이 가능하다.  테스트 코드를 작성하며 개발하는 도중, 한 선배 개발자가 프로젝트의 패키지 구조를 대대적으로 변경한 적이 있다. 당연히 내가 작성한 코드에도 영향이 있었고, 처음에는 큰 변화에 대한 두려움이 있었다. 실제를 conflict를 스스로 해결해 보았는데, 테스트코드 때문에 오히려 심리적 안전하다는 생각이 들었다.  그래서 리팩토링의 첫 단계는 테스트코드라고 말하는 것이다. 
네 번째는 설계의 개선이 가능하다는 것이다. 테스트코드를 작성을 쉽게 하기 위해서는 유연한 의존성이 필수적이다. 자연스레 코어 비즈니스로직과 세부사항을 분리를 하게 된다. 단위 테스트 대상 클래스와 협력하는 클래스 간의 의존성이라 메시지 규약도 고려를 하게 된다.
아주 가볍게 내가 생각하는 이유들을 적어 보았다. 동의하는 부분도 있을 테고 동의하지 않는 부분도 있을 것이다. (다양한 의견 환영합니다.) 나도 이 글을 쓰면서 이 글을 읽으시는 분들에게 빠르게 피드백을 받고자 하는 목적도 있기 때문이다. 
빠른 피드백, 유연한 의존성, 그리고 리팩토링의 용이성을 갖추어 나가다 보면 어제 보다 나은 코드를 만들기 위한 프로덕트의 기본 바탕이 될 수 있지 않을까 생각한다.  다음에는 좀 더 구체적인 사례로 테스트 코드 작성을 어떻게 할 수 소개해 보도록 하겠다.

테스트코드 작성 하시나요?

댓글