테스트 케이스를 작성하지말자.

글 제목은 나도 한번 어그로 끌고싶어서 작성했다....

 

외부 API를 사용할 때 그 외부 API 기능에대한 테스트 케이스에대한 나의 고민을 적어보려한다.

 

어제 AWS S3를 이용해 이미지를 업로드하는 기능의 개발을 마치고 테스트 코드를 작성중..

S3의 경우 Service Layer의 통합테스트 진행시 

실제 S3객체를 이용해 테스트할시 테스트를 진행 할 때마다 S3로 업로드가 진행되어 프리티어를 이용하는 나에겐 큰 부담이 됬다. 

(비용을 떠나서 E2E테스트도 아닌 통합 테스트인데 굳이 S3에 이미지를 보내야하나 싶기도하고...)

 

구글링을 통해 S3 를 모킹 할 수 있는 객체를 발견했고 테스트를 코드를 작성하기위해 실제 프로덕션 코드를 보다...

문득 StackOverFlow에서 우문현답을 찾았던 경험이 들었다..

 

그 때 당시에도 나는 동시성문제로 JPA의 PessimisticLock 기능을 테스트하기위해 구글링을 진행했는데 

나와 같은 질문을 하는 글이 있어 확인해보았는데 그에 달린 답변이....

답변을 보고 

한 대 맞은 느낌이 들었다...

만약 정말 테스트를 통해 외부 API의 문제가 있는거라면

JPA를 내가 직접 고칠것인가?

or

해당 API를 사용하지않을건가?

 

관성적으로 테스트 코드를 작성하려했던 나에게 중요한 의미를 떠올리게해준 답변이였다.

"테스트 코드를 위해 테스트코드를 작성하지마라"

 

 

다시 S3 테스트에 돌아와 현재 내 코드를 보니 문득 위의 기억이 떠올랐다..

 

S3 업로드의 역할만을 가진 클래스.

 

테스트를 진행하려했던 위 클래스의 메서드는 단 1개다.

uploadToS3 메서드에는 putObject() 라는 amazonS3 객체의 외부 API빼고는 

딱히 테스트를 진행 필요가 없는 코드들 뿐이였다. 

 

이 상황에서 uploadToS3 테스트를 진행해서 내가 얻을 수 있는점은 미비하다고 판단

( 테스트 코드를 통해 해당 메서드의 문서화가 가능하겠지만, 간단한 로직의 메서드기때문에 내가아닌 다른 개발자가봐도

실제 메서드만 봐도 충분히 이해 할 수있는 메서드라 생각한다. )

 

S3 Mock은 나중에 언젠가 사용할 날이 오겠지

 

 

테스트 코드는 항상 옳다.

하지만 그 관념에 사로잡혀

테스트를 위한 테스트코드를 작성하는 오버 엔지니어링을 범하지말자.