정의

단위테스트는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다.

즉, 회사에서 혹은 개인이 어떠한 기능을 위해서 작성했던 프로그램 안에 있는 모든 함수와 메소드가 믿을만한 코드인가에 대한 테스트 케이스를 작성하는 절차를 말한다.

이를 통해서 언제라도 코드 변경으로 인해 문제가 발생한 경우, 단시간 내에 이를 파악하고 바로 잡을수 있도록 해준다.

이상적으로, 각 테스트 케이스는 서로 분리되어야 한다.

이를 위해 가짜 객체(Mock object)를 생성하는 것도 좋은 방법이다.

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

Why, 단위테스트를 작성해야하는 이유

그동안 우리는 정상동작 확인을 위해서

새로고침을 통해 실제 코드가 정상동작되는지, 포스트맨을 호출하여 정상동작되는지를 확인해 봤을 것이다.

이는 하나의 전체 기능을 확인 할 수 있으며 각각의 단일 함수, 기능들이 제대로 동작되는지에 대한 불안감은 해소시킬 수 없었다.

즉, 프로그램을 작은 단위로 쪼개서 각 단위가 정확하게 동작하는지 검사하는 것이다.

장점 : 문제점 발견, 변경 용이, 통합이 간단

• 코드 수정에 자신감이 생기고

• 프로그램의 안정성이 높아지고

• 문제 발생시 정확하게 어느 부분이 잘못되었는지를 재빨리 확인 할 수 있게 해준다.

• 내가 변경한 부분이 어디에 영향을 끼치는지 쉽게 파악할 수 있다.

• 새로운 인력이 팀에 합류했을때, 개발 스타일, 표준, 컨벤션 등을 공유하기에 좋다.

• 테스트를 잘 갖춰놓으면 문서를 따로 만들지 않더라도 자연히 코드 사용법을 알려주는 문서가 됨

• 언제라도 단위테스트를 믿고 리팩토링을 할 수 있고 리팩토링 후에도 해당 모듈이 의도대로 작동하고 있음을 단위테스트를 통해서 확신할 수 있다.

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

좋은 단위테스트 특징 : FIRST

좋고 깨끗한 테스트 코드는 FIRST라는 5가지 규칙을 따라야 한다.

• Fast: 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.

• Independent: 각각의 테스트는 독립적이며 서로 의존해서는 안된다.

• Repeatable: 어느 환경에서도 반복 가능해야 한다.

• Self-Validating: 테스트는 성공 또는 실패로 bool 값으로 결과를 내어 자체적으로 검증되어야 한다.

• Timely: 테스트는 적시에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다.

  • 실제로 프로그램 작성전 테스트코드를 작성했을 때 좀 더 많은 고려와 다른 문제점을 발견 할 수 있어서 이래서 테스트 코드를 미리 짜라고 하는거구나! 하고 생각했다.

작성법

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

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

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

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

  • 1개의 테스트 함수에 대해 assert를 최소화하고 1가지 개념만은 테스트한다.

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

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

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

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

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

이런경우에 메소드를 더 작게 분리하자

• 작성한 코드를 다른 직원들에게 설명할 때 ‘and’라는 단어를 사용했다면 그 메소드는 적어도 하나 이상의 부분으로 나눠야 한다!!

• 많은 일을 하는 코드는 테스팅-디버깅이 어렵다.

  • 위 문제를 해결하기 위해 많은일을 하지 않는 코드를 작성하는 것이다.

  • 각각의 함수를 단 한가지만의 일을 하도록 작성해야 단위테스트로 쉽게 테스트할 수 있다.

목차

• 단위테스트 > 예제
• 단위테스트 > set up
• 단위테스트 > Assert 함수들
• 단위테스트 > @Annotaion

그밖에 알아볼것들..

• test doubles
• code coverage

마치며

테스트 코드를 작성하는것이 중요하다는 말만 듣고 찔끔거리다가 제대로 알고 작성해야겠다는 생각이 들어서 찾아서 정리한 글입니다.
실제로 테스트코드를 작성하고 돌려보면서 문제있는 데이터를 발견하기도 해서 조금씩 중요성을 알아가고 있습니다 : )
다음 글에서는 영문으로 되어져 있는 예제 살펴본것중에 자주 쓰일 것 같은 부분 위주로 정리해볼 예정입니다.