테스트 코드는 어디 부터 시작해야할까?

1. 테스트 코드를 반드시 작성해야할까?

테스트 코드로 프로그램을 테스트 해야하는 이유가 무엇일까? 지금까지는 어플리케이션을 직접 동작시키고 Chrome 브라우저나 Postman을 통해서 직접 입력을 넣고 출력값을 비교하는 방식으로 테스트를 하였다. 물론 이렇게 테스트를 하는 것도 하나의 방법이지만 치명적인 단점이 있다. 그것은 바로 어플리케이션 전체를 구동한 뒤 테스트를 진행하기 때문에 프로젝트의 크기가 커질수록 실질적으로 테스트하는 시간보다 어플리케이션을 동작시키는 데 드는 시간이 오래걸릴 수 있다. 심지어 수정을 할 때마다 프로그램을 매번 다시 동작시켜야하는데 이게 누적될 수록 시간적인 손해는 간과할 수 없을 정도가 된다.

또한 테스트 코드를 통해 테스트를 진행하면 얻을 수 있는 장점이 한가지 더 존재한다. 바로 테스트 코드를 이용해 테스트를 진행하는 것 자체가 해당 메소드가 정상적으로 동작한다는 것을 문서화하는 것이기 때문에 추후에 별도로 문서화할 필요가 없다.

 

2. 그렇다면 대체 어디서 부터 테스트코드를 시작해야할까?

처음 테스트 코드를 작성할 때 가장 어려웠던 것은

 대체 어떤 것부터 시작해야하는거야?! 세세한 Getter, Setter 부터 다 테스트를 해야해? 너무 많은데??!

그렇다. 첫 삽을 뜨는 것부터 어려웠다. 가장 기초적인 것부터 테스트를 진행해야 한다고 생각하면,

1. 객체가 정상적으로 생성되는가?
2. 해당 객체의 Getter, Setter는 잘 동작하는가?
3. 해당 객체의 Constructor는 정상적으로 동작하는가?
4. ... etc

이렇게 테스트 코드의 양이 너무 많아져서 테스트 코드를 작성하는 시간이 기존의 프로젝트를 동작시켜서 테스트하는 것보다 오래걸릴 것 같아서 아무리 생각해도 정상적이라 생각할 수 없었다. 그렇다면 테스트 코드를 작성하는 적당한 수준의 범위는 무엇일까?

3. 사용자(Client)의 관점에서 테스트 대상을 선정하자!

즉, 사용자가 접근할 수 있는 기능 단위로 테스트를 진행한다고 생각하면 편하다.

프로그램을 개발하는 입장에서 개발자가 볼 수 있는 메소드들은 정말 다양하다. 때문에 모든 메소드들을 테스트해야만 할 것 같은 생각이 들고 실제로 이렇게 테스트를 진행하면 시간적으로 엄청난 부담이 된다. 하지만, 작성한 코드에서 한 발자국 떨어져 사용자의 입장에서 생각하면 적절한 테스트 단위를 선정할 수 있다. 

 

예를 들어, 다음과 같은 상황을 가정해보자. 사용자가 장바구니에 상품을 담는 과정을 생각해보자. 이를 위한 메소드는 "addProduct"이다.

사용자가 해당 기능을 사용할 때 예상하는 결과는 다음과 같다.

• 입력 : " A 상품에 대해 [상품 추가] 하는 버튼을 누르면"
• 출력 : " 장바구니에 A상품이 추가되겠지?"

그렇다면 우리는 해당 기능을 구현하기 위한 메소드인 addProduct를 테스트하면 된다. 그 메소드 안에서 세부적으로 객체를 생성하거나 레포지토리에 추가하는 것 등은 굳이 테스트하지 않아도 된다. 왜냐하면 추후에 리팩토링하는 과정에서 해당기능을 구현하기 위한 내부의 보조적인 메소드들은 얼마든지 변할 수 있기 때문이다.

 

물론 테스트의 범위를 정하는 명확한 정답은 존재하지 않는다. Getter와 Setter부터 테스트를 진행하고 싶다면 그렇게 하면 된다.

하지만 효율적인 테스트를 진행하고 싶다면 위의 의견을 기반으로 테스트를 진행하는 것도 좋은 방법이 될 것이라 생각한다.