테스트코드의 필요성

들어가며

5개월 전, 테스트코드를 처음 작성하면서 이런 생각을 했다.

 

'이거... 테스트 통과하는 게 당연한 거 아니야...?'

'given에서 조건을 다 주고 테스트하는데 당연히 통과하지... 이럴 거면 왜 테스트코드를 작성하는 거지?'

'내가 뭔가 잘못 작성하고 있나?'

 

멘토님은 테스트코드의 필요성을 제대로 알지 못하면 그런 생각이 드는 게 당연하고,

심지어 '짜고 치는 거 아닌가'라는 생각이 드는 것도 맞게 생각한 거라고 하셨다.

여기에서 말하는 테스트코드의 필요성에는 어떤 게 있을까?

 

테스트코드를 왜 작성해야 하는지 알아보자.

 

필요성

DB 변경 없이 테스트

실무에서는 API 호출을 통해 동작을 테스트하기 어려운 경우가 많다.

실제 사용하는 DB를 변경하면 절대 안되기 때문에 로컬 환경이 아닌 이상,

포스트맨으로 테스트하기는 어려우며 테스트코드를 통해 동작을 시험해 봐야 한다고 한다.

 

API 스펙의 규격화

그 뿐만이 아니다.

이건 멘토님이 말씀해주시기 전에는 정말 생각지도 못한 내용이었는데,

테스트코드로 API의 스펙을 규격화할 수 있다는 것이었다.

 

테스트 커버리지가 높을수록 API 스펙은 보다 규격화된다.

로그인 API를 통해 이게 어떤 의미인지, 테스트코드가 왜 필요한지 더 자세히 알아보자.

 

예시

API : 이메일과 비밀번호를 받아 유효한 유저인지 검증하고, jwt를 보낸다.

 

1. 이메일이 입력되지 않은 경우 예외를 발생시킨다.

2. 이메일 형식이 아닌 경우 예외를 발생시킨다.

3. 비밀번호가 입력되지 않은 경우 예외를 발생시킨다.

4. 비밀번호가 20자를 넘은 경우 예외를 발생시킨다.

5. 비밀번호가 6자 미만인 경우 예외를 발생시킨다.

 

이 정도의 테스트코드를 작성했다고 생각해보자.

어떤 이유로 내가 담당하던 이 API는 B가 담당하게 되었는데, B는 이 회사의 로그인 정책을 몰랐고...

결국 B는 이메일이 아니라 아이디를 입력하도록 코드를 변경했다.

변경 후 B가 어플리케이션을 실행하려고 할 때, 테스트2가 실패한다.

 

이런 어이없는 변경은 아무도 하지 않을 것이다.

하지만 이게 더 중요한 비즈니스 로직이고,

옳다고 생각하는 범위 안에서 좀 더 미묘한 변경을 했더라도 해당 API의 스펙을 벗어났다면 테스트가 실패할 것이다.

 

이런 방식으로, 테스트코드를 작성하면 API 스펙을 규격화하게 되는 것이다.

 

마치며

테스트코드를 작성하기 전에, 그 필요성을 깨닫게 되면 (짜고 치는) 테스트코드 작성이 즐거워진다.

다음 글에서는 테스트코드를 작성하는 방법에 대해 안내하려고 한다.

 

(나는 아직 못하고 있지만) 테스트 커버리지를 높이자!