10장 - 단위 테스트의 원칙

시스템이 멈추면 개발자 하는 유명한 말

 

딱 한 줄 고쳤는데요..

 

코드 변경은 언제나 위험합니다.

테스트는 이런 수정에 대한 안정장치입니다.

 

단위 테스트라는 정의에 너무 크게 신경 쓸 필요 없습니다.

중요한 것은 코드를 잘 테스트하고 이 작업을 유지보수할 수 있는 방법으로 수행하는 점입니다.

 

형편없는 테스트는 아예 테스트가 존재하지 않는 경우이지만 테스트가 존재해도 좋은 테스트를 작성하는 것이 중요합니다.

 

좋은 단위 테스트 작성방법

• 훼손의 정확한 감지
• 세부 구현 사항에 독립적
• 잘 설명되는 실패 - 우리가 흔히 쓰는 assert구문을 쓰면 실패에 대한 설명을 명확하게 알 수 있다.
• 이해할 수 있는 테스트 코드 - 테스트 코드도 유지보수 해야 할 수 있기 때문에 읽기 쉽게 만들어야 한다.
• 쉽고 빠르게 실행 - 테스트를 실행하는데 1시간이 걸리다면 테스트를 실행하기 꺼려진다.

 

훼손의 정확한 감지

 

현재 코드에 대한 신뢰를 주고, 수정이 발생했을 때 미래에 대한 훼손을 막아줍니다.

테스트 대상 코드가 정상임에도 때로는 통과하고 때로는 실패할 수 있습니다.

random, race-condition, timing 등의 이슈가 있다면 어떨 때는 통과하고 어떨때는 실패할 수 있습니다.

 

이런 경우를 플래키 테스트라고 하는데 실패의 원인을 찾느라 시간이 낭비되고 정말 짜증 나면 아예 테스트를 비활성화할 수 있습니다.

코드에서 어떤 부분이 훼손될 때 그리고 오직 훼손된 경우에만 테스트가 실패하도록 하는 것은 매우 중요합니다.

 

세부 구현 사항에 독립적

우리는 기능적 변화, 리팩터링 등을 수행할 수 있습니다.

 

이때 리팩터링을 수행하고 f(x) = y가 나온다고 가정해 보겠습니다.

이때 리팩터링을 수행하고 동일한 input, output을 나온다면 우리는 리팩터링을 잘 되었다고 생각할 수 있습니다.

 

하지만 테스트를 작성할 때 input, output이 아니라 중간 과정인 세부사항까지 테스트하면 어떨까요?

멤버 변수의 중간 상태 등을 확인하는 테스트가 들어가면 해당 중간 상태에 대한 세부사항이 바뀐 경우 사실문제없이 잘 동작하지만 테스트는 실패할 것입니다.

 

따라서 세부 구현 사항에 독립적으로 테스트를 작성하는 것이 좋습니다.

 

그렇다면 private api는 테스트하지 않고 public api만 테스트해야 한다는 것을 의미합니다.

하지만 중요한 동작이 private method에 있다면 해당 동작을 테스트해야 할 수 있습니다.

우선 public api를 활용하여 private method를 테스트해 보고 그럴 수 없다면 클래스로 추출하여 테스트하는 방법을 취할 수도 있습니다.

 

테스트 더블

test dobule이라고 부르는 mock, stuc, fake 등으로 테스트에 필요한 의존성을 대안으로 사용할 수 있습니다.

보통 DB 쓰기 등의 side-effect를 대체하기 위해 사용합니다.

 

fake - 실제로 사용된 객체는 아니지만 같은 동작을 하는 구현된 객체 (like in-memory db)

stub - 미리 정의된 데이터를 보유하고 테스트 호출 시에 응답하도록 사용되는 객체

mock - 행위가 일어났는지는 검증하기 위해 사용되는 객체

 

mock과 stub은 실제 의존성과 다른 방식으로 동작하도록 설정될 가능성이 있습니다.

또한 구현 세부사항과 테스트가 밀접하게 결합되어 리팩터링이 어려워질 수 있습니다.

 

가능한 한 실제 의존성이 사용되면 좋고 불가능하다면 차선책으로 fake를 선택, mock과 stub은 최후의 수단으로 사용해야 합니다.