Testable Code 작성을 위한 노력 1

난 테스트 코드 작성을 좋아하기도하고 중요하게 생각한다.

 

왜냐면

 

녹색불이 뜨면 기분이좋다....

 

그렇다보니 테스트 코드에 대해 여러가지로 공부하려 노력을하는데 

어제 테스트 코드를 작성하기 어려운 메서드를 작성하게되어

Testable Code란 무엇일지 공부해봤다..

 

우선 문제의 메서드

 

문제점

메서드의 역할과 책임이 다양하다.

이미지 검증도하고... uuid로 이름 변환도하고....S3로 이미지 업로드도 진행하고....

 

해당 메서드의 테스트를 진행하려하니

참조하고있는 imageUploader 객체의 imageToS3의 메서드가 실행되지않아 테스트가 불가능해졌다...

 

테스트하기 좋은코드란 우선 역할과 책임이 단순 명료해야한다.

그렇기때문에 LayerArchitecture가 테스트 케이스에 이점을 가지고있는것아닌가

 

메서드의 역할을 좀 덜어내고자 리팩토링을 진행했다.

 

 

검증 후 바로 uuid로만 return하는 메서드로 리팩토링을 진행했고 메서드명도 이미지를 가공하는 메서드다보니 imageProcessing으로 바꿨다.

(애초에 validateImage()도 분리하려했지만 클래스에 public메서드가 너무 많아지고 public 메서드를 또 컨트롤러에 덕지덕지 작성하는것보단, validateImage() 까지는 포함하는게 맞다고 판단했다.)

 

 

컨트롤러에서 이미지 서비스가 반환한 uuid를 받고 uuid를 imageUploader 로 보내줘 

실질적인 업로드 기능을 수행한다.

 

 

이미지 업로더는 S3에 관련된 역할들만 모아둔 클래스로 S3로 업로드만 진행하는 역할을 갖게된다.

 

이로써,

만약 나의 웹 어플리케이션 정책이 S3를 사용하지않고 홈서버로 업로드를 진행으로 변경했을때 ImageUploader의 의존성 주입만 바꿔주면 되는 관심사의 분리가 명확하게 되었다.

 

그에따라 당연히 테스트 코드 작성도 간편해졌다.

이미지 서비스는 업로드를 진행하던말던 그저 이미지를 검증하고 가공하는 역할만 수행하면되니...

 

 

Testable Code한 코드를 작성하는 방법에는

여러가지가있지만 

 

우선 관심사의 분리를 명확하게 진행하는것이 첫번째 단계임을 다시 한번 깨닳았다.