단위테스트의 필요성에 대해서

처음 스프링을 공부하며 JUnit을 이용한 단위 테스트를 할 때 항상 의문을 느꼈습니다.

 

이런식으로 테스트 하는게 무슨의미가 있지?

직접 애플리케이션을 실행해서 눈으로 보면서 기능을 테스트하는게 더 좋은거 아니야?

그냥 직접 실행해서 테스트한다음 깃허브에 Push 해도 되는데?

 

그래서 테스트 코드에 대해서는 공부하지않고 코드만 따라치고 넘겼습니다.

 

최근에 이동욱님의 책을 읽으며 본 테스트 코드의 장점에는 3가지가 있었습니다.

 

- 빠른 피드백

- System.out.println() 을 통해 눈으로 검증하는것이 아닌 자동검증 가능

- 개발자가 만든 기능을 안전하게 보호

 

이것만 보면 아직 어떤 장점인지 와닿지 않습니다.

 

1. 빠른 피드백

단위 테스트 코드를 작성함으로써 얻는 이점에 대한 위키디피아의 글입니다.

• 단위 테스트는 개발단계 초기에 문제를 발견하게 도와줍니다.
• 단위 테스트는 개발자가 나중에 코드를 리팩토링하거나 라이브러리 업그레이드 등에서 기존 기능이 올바르게 작동하는지 확인할 수 있습니다.(예, 회귀 테스트)
• 단위 테스트는 기능에 대한 불확실성을 감소시킬 수 있습니다.
• 단위 테스는 시스템에 대한 실제 문서를 제공합니다. 즉, 단위 테스트 자체가 문서로 사용할 수 있습니다.

보통 제가 테스트하는 방식은 다음과 같습니다.

1. 기능을 만들고 (또는 수정하고)
2. 톰캣을 실행한 뒤
3. 사이트에 접속해 잘 작동하는지 확인합니다.
4. 예외가 생기면 톰캣을 중지합니다.
5. 코드를 수정하고 1번부터 반복합니다.

저는 이런과정을 당연하다고 생각했지만 책에는 다음과 같이 나와있습니다.

 

톰캣을 실행하는데 수십초에서 1분 이상이 소요되기도 하며 수십 번씩 수정해야 하는 상황에서 아무런 코드 작업 없이 1시간 이상 소요되기도 합니다. 왜 계속 톰캣을 내렸다가 다시 실행하는 일을 반복할까요? 이는 테스트 코드가 없다 보니 눈과 손으로 직접 수정된 기능을 확인할 수 밖에 없기 때문입니다. 테스트 코드를 작성하면 이런 문제가 해결되므로 굳이 손으로 직접 톰캣을 계속 올렸다 내렸다 할 필요가 없습니다.

이걸 보니 테스트 코드가 주는 편안함이 조금씩 보였습니다.

 

 

2. 자동검증

테스트 코드를 작성하면 더는 System.out.println() 을 사용해 사람의 눈으로 검증하지 않게 자동검증이 가능합니다.

작성된 단위테스트를 실행만 하면 더는 수동 검증이 필요 없는것입니다.

 

3. 개발자가 만든 기능을 안전하게 보호

B라는 기능을 만들어 잘 작동하는 것을 확인하고 배포했더니 기존에 잘 작동하던 A 기능에 문제가 생기는 경우가 있습니다. 하나의 기능을 추가할 때마다 너무나 많은 자원이 들기 때문에 서비스의 모든 기능을 테스트할 수는 없습니다.

이렇게 새로운 기능이 추가될 때, 기존 기능이 잘 작동되는 것을 보장해 주는 것이 테스트코드 입니다. A라는 기존 기능에 기본 기능을 비롯해 여러 경우를 모두 테스트 코드로 구현해 놓았다면 테스트 코드를 수행하는 것으로 모든 문제를 조기에 찾을 수 있습니다.

 

 

3가지 이유를 보니 단위 테스트는 선택이 아니라 필수라고 생각됩니다.

 

가장 중요한것은 내가 만든 서비스에 안전장치 역할을 하는것이 단위 테스트라는 것입니다.

 

테스트가 실패하면 어디서 어떤 문제가 발생했는지 알 수있고

테스트 케이스가 많으면 많을 수록 더욱 안전을 보장하는 서비스를 만들 수 있습니다.

 

테스트 케이스를 작성하는 것은 귀찮은 일이 될 수 있지만 그로인해 미래에 생기는 효과는 훨씬 가치있는 일이 될거라고 생각합니다.