Unit Test에 대한 오해 풀기

유닛 테스트의 개념을 잘못 알아 테스트를 위한 테스트 코드가 되는 순간

새로운 기능을 구현할 때마다, 에러가 발생하는 테스트 코드를 다시 짜야하는 뻘짓을 하게 된다.

테스트 코드를 제대로 구현하기 위해 유닛 테스트에 대해 알아보고자 한다.

 

유닛 테스트의 유닛은 함수 하나를 가리키는 게 아니다.

유닛을 어떻게 정의 하느냐에 따라서 단순한 함수 하나를 테스트할 수도 있고

하나 이상의 함수 등이 합쳐진 코드를 테스트할 수도 있다.

 

예를 들어 전자렌지의 성능을 높인다고 해보자.

시작 버튼을 눌렀을 때 좀 더 효율적으로 돌아가도록 트렌지스터를 교체한다고 하자.

이 과정에서 어떤 트렌지스터를 쓸지, 몇개나 쓸지 등의 직접적인 코드 구현은 어떻게 해도 상관이 없다.

중요한 것은 시작 버튼을 눌렀을 때 이전과 동일하게 잘 작동을 하는지이다.

 

따라서 전자렌지의 시작 버튼을 눌렀을 때 호출되는 작은 함수 하나하나를 테스트하는 것은 의미없다.

함수 하나를 유닛으로 두고 테스트를 한다고 해서 앱이 제대로 돌아가는지 보장할 수 없다.

그런 코드보다는 버튼을 눌렀을 때 불이 들어온다거나 작동한다거나 등의 논리를 생각하는 게 먼저인 것 같다.

전자렌지의 시작 버튼에 대한 단위 테스트를 하는 거다.

 

Test behaviour, not implementation.

(테스트는 코드를 변경하더라도 앱의 기능이 모두 잘 작동하는지 확인하는 용도)

 

함수 하나하나를 테스트하는 걸 두고 solitary test라 하고

앞서 설명한 테스트를 social test라고 한다.

유닛 테스트는 이중 어느 하나만을 가리키는 게 아니다.

 

반면 함수 하나가 지나치게 복잡할 경우 solitary test를 해야 할 수도 있다.

 

주의점

유닛 테스트의 장점 중 하나는 속도다.

응답 시간이 걸리는 api 요청과 같은 외부 요소들을 배제하고 테스트 하기 때문에 속도가 빠르다.

때문에 테스트 중간에 api 요청이 있으면 mock을 사용해야 한다.