단위테스트란? (정의, 목적, 장점, 작성법)

단위테스트

정의

유닛 테스트(unit test)는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다.
즉, 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차를 말한다.

이를 통해서 언제라도 코드 변경으로 인해 문제가 발생할 경우, 단시간 내에 이를 파악하고 바로 잡을 수 있도록 해준다. 이상적으로, 각 테스트 케이스는 서로 분리되어야 한다.

이를 위해 가짜 객체(Mock object)를 생성하는 것도 좋은 방법이다. 유닛 테스트는 (일반적인 테스트와 달리) 개발자(developer) 뿐만 아니라 보다 더 심도있는 테스트를 위해 테스터(tester)에 의해 수행되기도 한다.

유닛 테스트는 일견 개발 시간을 증가 시키는 것처럼 보이지만 개발 기간 중 대부분을 차지하는 디버깅 시간을 단축시킴으로써 여유로운 프로그래밍을 가능케 한다.

왜 단위테스트 소스를 작성해야 하는가?

내가 오래전에 짠 코드, 다른 팀원들이 짠 코드는 수정하기가 무섭다.

단 몇십 줄의 코드를 작성하더라도 내 코드가 의도대로 동작하는지 확인하려면 WAS에 올려서 확인해 왔을 것이고 오류가 발생하면 디버깅을 통해서 확인하는 작업을 반복했을 것이다.

WAS에 올려서 확인하던 main() 메서드를 쓰던 HTTP request를 날려보던 테스트가 필요한데 어차피 테스트할 거 유닛테스트로 만들어서 계속 확인하지 않을 이유가 없다.

테스트 케이스들은 내가 가입한 보험과 같다.

내가 작성한 코드가 수정 후에도 계속 동작하고 배포된 후에도 '문제가 생기지 않을거야' 최소한의 안정성을 기대할 수 있고 퇴근 후에도 안심할 수 있다.

목적

유닛 테스트의 목적은 프로그램의 각 부분을 고립 시켜서 각각의 부분이 정확하게 동작하는지 확인하는 것이다. 즉, 프로그램을 작은 단위로 쪼개서 각 단위가 정확하게 동작하는지 검사하는 것이다.

장점

키워드 : 문제점 발견, 변경이 쉬움, 통합이 간단.

• 코드 수정에 자신감이 생긴다.
• 프로그램의 안정성이 높아진다.
• 문제 발생 시 정확하게 어느 부분이 잘못되었는지를 재빨리 확인할 수 있게 해준다
• 내가 변경한 부분이 어디에 영향을 끼치는지 쉽게 파악할 수 있다.
• 새로운 인력이 팀에 합류했을때, 개발 스타일, 표준, 컨벤션등을 공유하기에 좋다.
  • 테스트를 잘 갖춰놓으면 문서를 따로 만들지 않더라도 자연히 코드 사용법을 알려주는 문서가 된다
• 언제라도 유닛 테스트를 믿고 리팩토링을 할 수 있고 리팩토링 후에도 해당 모듈이 의도대로 작동하고 있음을 유닛 테스트를 통해서 확신할 수 있다.

  정리하면 문제를 빨리 발견하고 변화를 쉽게하며 통합을 간단하게 하고 설계를 개선할 수 있다는 것이다.

작성법

• 하나의 테스트케이스에 최소한의 기능만 검증하고, 최대한 간결하게 작성한다.

  Anti Pattern ) 클래스에 하나의 메소드를 하나의 테스트케이스 함수로 작성하는 경우

  조건문, 반복문, 분기문이 있으면 하나의 메소드라 할지라도, 검증 대상은 여러 상황이 있는 것이다. 이를 하나의 테스트케이스 함수에서 검증하는 것은 너무 어렵다.

  테스트케이스의 소스길이가 길어지고, 중간에 에러가 발생하면 어떤 상황에서 실패했는지 살펴보는데 추가적으로 시간이 든다. 이는 테스트를 유지보수하기에 비효율적인 방법이다.

• 입력값에 대한 결과 값을 검증하는 방식으로 작성하라.

  기본적으로는 입력값에 대한 결과값을 확인하는 방식으로 작성하면 소스가 변경되더라도 테스트케이스를 변경할 일이 훨씬 적다.

• 불안한 부분이 없도록, 개발하는 부분은 최대한 커버하라.

  최대한 꼼꼼하게 작성해야 테스트케이스의 효과를 최대한 얻을 수 있다.

  커버리지 수치는 꼼꼼하게 단위테스트를 작성하면 따라온다. 결코 커버리지 수치 자체가 목적이 되어서는 안된다. 수치가 목적이 되는순간 의미없는 테스트를 작성하고, 단위테스트를 통해서 얻고자 하는 효과가 적어진다.

• Third Party Library의 기능은 믿고, 단위테스트 검증대상에서 제외하라.

  효율적인 개발을 위해 적용한 라이브러리 또는 플러그인의 기능은 정상적으로 동작할거라 믿고 단위테스트 검증 대상에서 제외한다.

• 좋은글 (

  메소드를 더 작게 분리해야 하는지에 대해 판단할 때 사용하는 문구가 있다.
  만약 코드의 역할을 다른 프로그래머에게 설명할 때 ‘and’라는 단어를 사용했다면 그 메소드는 적어도 하나 이상의 부분으로 나눠야 한다는 것이다.

  ‘많은 일을 하는 코드는 테스팅이 어렵다.’

  ‘많은 일을 하는 코드는 디버깅이 어렵다.’

  이 두 가지 문제의 해결법은 많은 일을 하지 않도록 코드를 작성하는 것이다.
  각각의 함수를 단 한가지만의 일을 하도록 작성해야 한다.
  이렇게 하면 단위 테스트로 쉽게 테스트할 수 있다. (하나의 함수에 대해 많은 단위 테스트가 필요하지 않는다.)

참고

1. https://ko.wikipedia.org/wiki/%EC%9C%A0%EB%8B%9B_%ED%85%8C%EC%8A%A4%ED%8A%B8
2. http://softwareengineering.stackexchange.com/questions/195989/is-it-ok-to-split-long-functions-and-methods-into-smaller-ones-even-though-they/195992#195992
3. https://www.popit.kr/unit-test-%EB%8B%A8%EC%9C%84-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EB%8F%84%EC%9E%85%ED%95%98%EA%B8%B0-2%ED%8E%B8/