<div id="readability-page-1" class="page"><article>
    <div>

                
                

				<h2 id="개요">개요</h2>

<p>유닛 테스트 (단위 테스트)가 필요하다는 것은 다들 동의하고 이해하고 있다.</p>

<p>사실 개발 과정에 자연스레 녹여낸다면 더 할 나위 없겠지만, 그렇지 않은 경우의 팀도 꽤 많을 것이다.</p>

<p>나는 많은 좋은 팀들이 실천하고 있는 유닛 테스트를 개발 과정에 포함시키지 못하는 팀에서 시도 해볼만 한 유닛 테스트의 시점과 방법에 대해서 얘기해보고자 한다.</p>

<p>이미 유닛 테스트를 잘하는 팀이라도, 유닛 테스트 추가 시점은 참고 할 만 하지 않을까 싶기도 하다.</p>

<h2 id="유닛테스트작성-시점">유닛&nbsp;테스트&nbsp;작성 시점</h2>

<h2 id="개발-과정">개발 과정</h2>

<ul>
  <li>개발 과정에서&nbsp;내 코드에 대한 검증 테스트</li>
  <li>자신이 버그를 만드는 패턴을 떠올리고, 그 패턴을 방지하고 검증하는 테스트가 추가되면 아주 효율적임</li>
</ul>

<h2 id="qa-서비스-과정">QA, 서비스 과정</h2>

<ul>
  <li>버그가 나오면, 그 버그를 수정하기 위한 테스트
    <ul>
      <li>재발 했을 때 감지될 테스트</li>
    </ul>
  </li>
  <li>테스트&nbsp;추가 iteration 후의&nbsp;효과
    <ul>
      <li>테스트 1주일 했다면, 대다수의 기본 기능에 대한 테스트셋이 나옴</li>
      <li>이후&nbsp;해당&nbsp;다른&nbsp;수정&nbsp;시, 기존의&nbsp;기능들이&nbsp;깨지지&nbsp;않는다는&nbsp;것을&nbsp;유닛&nbsp;테스트로&nbsp;감지&nbsp;할&nbsp;수&nbsp;있게&nbsp;됨</li>
    </ul>
  </li>
</ul>

<h2 id="테스트가-지켜-줘야-하는-부분">테스트가 지켜 줘야 하는 부분</h2>

<h2 id="유닛테스트방법의-주요-예시">유닛&nbsp;테스트&nbsp;방법의 주요 예시</h2>
<ul>
  <li>정상적인&nbsp;상황</li>
  <li>실패해야만&nbsp;되는&nbsp;상황</li>
  <li>범위를&nbsp;벗어난&nbsp;입력
    <ul>
      <li>주로&nbsp;변수의&nbsp;타입을&nbsp;가정하고, overflow, underflow를&nbsp;중점적으로&nbsp;확인하되, 가정한&nbsp;임계치가&nbsp;있다면, 그&nbsp;임계치의&nbsp;경계&nbsp;값을&nbsp;확인하면&nbsp;더&nbsp;좋다.
        <h2 id="유닛테스트에서확인해야될내용">유닛&nbsp;테스트에서&nbsp;확인해야&nbsp;될&nbsp;내용</h2>
      </li>
    </ul>
  </li>
  <li>호출&nbsp;순서에&nbsp;영향이&nbsp;없는지
    <ul>
      <li>만약&nbsp;있어야&nbsp;한다면, 호출&nbsp;순서가&nbsp;뒤바뀌어도&nbsp;문제가&nbsp;없는지</li>
    </ul>
  </li>
  <li>범위가&nbsp;넘어서는&nbsp;값이&nbsp;전달&nbsp;될&nbsp;때에도&nbsp;잘&nbsp;핸들링&nbsp;하는지</li>
  <li>함수&nbsp;리턴&nbsp;값&nbsp;실패로&nbsp;반환할&nbsp;내용이&nbsp;예외로&nbsp;전달되고&nbsp;있는지
    <h2 id="외부-툴-커스텀한-스크립트나-툴로추가진행해야될테스트-유닛-테스트-범주-외">외부 툴, 커스텀한 스크립트나 툴로&nbsp;추가&nbsp;진행해야&nbsp;될&nbsp;테스트 (유닛 테스트 범주 외)</h2>
  </li>
  <li>성능이&nbsp;중요한&nbsp;경우&nbsp;성능&nbsp;테스트.</li>
  <li>멀티스레딩&nbsp;이슈&nbsp;등이&nbsp;있는&nbsp;경우에는&nbsp;반복&nbsp;테스트</li>
  <li>성능도&nbsp;임계치에&nbsp;근접할&nbsp;때 자원이 (메모리, CPU) 잘&nbsp;방어되고&nbsp;있는지를&nbsp;확인하는&nbsp;테스트를&nbsp;진행해야&nbsp;한다.</li>
</ul>

<h2 id="마치며">마치며</h2>

<p>테스트를 왜 하는가?</p>

<p>그 이유에 대해서 공감하지 못하거나, 어떤 효과를 원하는지에 대해서 합의나 이해가 없어서 비 효율적인 테스트, 혹은 효과적이지 못한 테스트, 있어서 나쁠건 없는 테스트 코드 들이 생산되고 이에 대한 코스트만 커지는 경우도 많이 보게 됐다.</p>

<p>그래서 내가 일해오면서 효과를 많이 본 테스트, 높지 않은 코스트로 가능한 테스트에 대해서 간략하게 정리해보았다.</p>

<p>유닛 테스트를 넘어선 스트레스 테스트, 부하 테스트에 대한 이야기는 추후 작성하도록 하겠다.</p>


                <hr>
                
                <hr>

                
                
                
                
                

                
            </div>
</article></div>

Elky Essay

개요
유닛 테스트 (단위 테스트)가 필요하다는 것은 다들 동의하고 이해하고 있다.
사실 개발 과정에 자연스레 녹여낸다면 더 할 나위 없겠지만, 그렇지 않은 경우의 팀도 꽤 많을 것이다.
나는 많은 좋은 팀들이 실천하고 있는 유닛 테스트를 개발 과정에 포함시키지 못하는 팀에서 시도 해볼만 한 유닛 테스트의 시점과 방법에 대해서 얘기해보고자 한다.
이미 유닛 테스트를 잘하는 팀이라도, 유닛 테스트 추가 시점은 참고 할 만 하지 않을까 싶기도 하다.
유닛 테스트 작성 시점
개발 과정
개발 과정에서 내 코드에 대한 검증 테스트
자신이 버그를 만드는 패턴을 떠올리고, 그 패턴을 방지하고 검증하는 테스트가 추가되면 아주 효율적임
QA, 서비스 과정
버그가 나오면, 그 버그를 수정하기 위한 테스트
    
재발 했을 때 감지될 테스트
테스트 추가 iteration 후의 효과
    
테스트 1주일 했다면, 대다수의 기본 기능에 대한 테스트셋이 나옴
이후 해당 다른 수정 시, 기존의 기능들이 깨지지 않는다는 것을 유닛 테스트로 감지 할 수 있게 됨
테스트가 지켜 줘야 하는 부분
유닛 테스트 방법의 주요 예시
정상적인 상황
실패해야만 되는 상황
범위를 벗어난 입력
    
주로 변수의 타입을 가정하고, overflow, underflow를 중점적으로 확인하되, 가정한 임계치가 있다면, 그 임계치의 경계 값을 확인하면 더 좋다.
        
유닛 테스트에서 확인해야 될 내용
호출 순서에 영향이 없는지
    
만약 있어야 한다면, 호출 순서가 뒤바뀌어도 문제가 없는지
범위가 넘어서는 값이 전달 될 때에도 잘 핸들링 하는지
함수 리턴 값 실패로 반환할 내용이 예외로 전달되고 있는지
    
외부 툴, 커스텀한 스크립트나 툴로 추가 진행해야 될 테스트 (유닛 테스트 범주 외)
성능이 중요한 경우 성능 테스트.
멀티스레딩 이슈 등이 있는 경우에는 반복 테스트
성능도 임계치에 근접할 때 자원이 (메모리, CPU) 잘 방어되고 있는지를 확인하는 테스트를 진행해야 한다.
마치며
테스트를 왜 하는가?
그 이유에 대해서 공감하지 못하거나, 어떤 효과를 원하는지에 대해서 합의나 이해가 없어서 비 효율적인 테스트, 혹은 효과적이지 못한 테스트, 있어서 나쁠건 없는 테스트 코드 들이 생산되고 이에 대한 코스트만 커지는 경우도 많이 보게 됐다.
그래서 내가 일해오면서 효과를 많이 본 테스트, 높지 않은 코스트로 가능한 테스트에 대해서 간략하게 정리해보았다.
유닛 테스트를 넘어선 스트레스 테스트, 부하 테스트에 대한 이야기는 추후 작성하도록 하겠다.

유닛 테스트의 범위

댓글