Test - Test 코드를 작성해야하는 이유와, 방법

1. Test Code를 왜 작성해야 하는가

우선 테스트코드를 작성하기 전, 우리가 왜 TestCode를 작성해야 하는지를 먼저 알아야, 귀찮은 테스트코드를 꼭 작성하려고 할것 같습니다.

 

 

1.1 궁극적 목표

테스트 코드를 작성하는 이유는, 잘 작동하는, 깔끔한 코드를 얻기 위해서 입니다.

 

그렇다면 왜 테스트코드를 작성하면, 깔끔한 잘 작동하는 깔끔한 코드를 얻을 수 있을까요? 테스트를 쉽게하기 위해서는, 어플리케이션 코드를 테스트하기 쉽게 짜야합니다. 결국 테스트 코드를 짜기 위해 노력하다보면, 어플리케이션 코드가 깔끔해진다! 는 말입니다.

 

 

 

1.2 시간의 단축

테스트 코드를 작성하면 귀찮고 시간도 되려 오래걸리지 않냐 라고 생각할 수 있지만,(옛날 얘기이니.. 요새는 이렇게 생각하는분은 없겠죠?) 오히려, 시간을 단축할 수 있습니다.

 

테스트 코드 작성 전 테스트 과정

예를들어, 우리는 웹 어플리케이션을 테스트하기 위해 다음을 반복합니다.

 

1. 코드를 수정한다.
2. 서버를 동작시킨다.
3. 필요에 따라 테스트에 필요한 데이터를 DB에 입력한다.
4. 브라우저를 통해 우리의 서버에 접속하고, 테스트 대상 메소드를 동작시키는 요청을 한다.
5. 테스트를 마치고, DB의 데이터를 정리한다.
6. 이 과정을 반복한다.

한, 두번 정도는 이렇게 할 수도 있겠지만, 알 수 없는 오류로 실패하는 경우, 계속해서 테스트를 위해서 위과정을 반복하게 됩니다. 많은 개발자 분들이위와 같은 상황을 경험하셨을테고, 매우 귀찮음을 느끼셨을겁니다. 또한 매우 시간이 오래 걸리기도합니다. 대부분이 이런 경험이 있으실거라고 생각합니다.

 

 

테스트 코드 작성 후 테스트 과정

이렇다한들, 그냥 한번더 서버를 동작시켜 테스트 하고말지, 테스트를 작성하겠다는 생각은 하기 힘듭니다. 저 또한 그랬었습니다. 하지만 테스트를 작성한다면 어떨까요?

 

1. 코드를 수정 한다.
2. 테스트 코드를 실행한다. (테스트 코드를 이미 작성했다는 가정)
3. 결과를 확인한다.

테스트 코드를 작성한다면, 코드 수정후 우리가 할일은 테스트 코드를 실행하는 일 뿐입니다. 잘 작성된 코드는 테스트 코드를 통해서 실행이 성공했는지 실패했는지 역시 알 수 있기 때문에, 매우 많은 시간을 절약할 수 있습니다.

 

 

 

1.3 장점

위에서 비교를 통해 알 수 있듯이 테스트코드를 통한 장점은 다음과 같습니다.

• 서버를 실행하는 등의 시간을 절약할 수 있다.
• 필요한 데이터를 미리 기입하고, 테스트가 끝나고 정리하는등의 행동을 하지 않아도 된다.
• 단위테스트의 경우 수십ms 이기 때문에 테스트가 매우 빠르다.
• 문서로서의 역할이 가능하다. -> 테스트 코드는, 개발자가 작성한 메소드가 어떻게 동작했으면, 어떤 결과를 반환했으면, 하는 것을 작성한 것이기 때문에 처음 코드를 보는 개발자들이 테스트 코드를 통해서, 코드의 동작을 조금더 수월하게 이해할 수 있다.

• 깔끔한 인터페이스를 얻어낼 수 있다. -> 아래에서 테스트 코드를 작성하는 방법을 살펴본다면, 왜 깔끔한 인터페이스를 얻을 수 있는지 알 수 있습니다.

 

 

 

 

2. 테스트 코드 작성 방법

예를들어 Person 클래스를 테스트한다고 해보도록 하겠습니다.

 

2.1 테스트 대상 행위를 정합니다.

예를들어, Person객체에 hi()라는 메소드에 매개변수로 String 타입의 name을 전달하여 호출하면.

 

2.2 기대하는 결과를 작성합니다.

"hi name"을 반환해야합니다.

 

2.3 두 문장을 결합해 테스트 코드로 작성한다.

사실 테스트코드랄께 별것 없습니다. 내가 작성한 코드가 어떤식으로 동작하기를 원하는 것을 코드로 표현하기만 하면 됩니다.

 

테스트 코드를 작성함에 있어 어려운 것은, 수 많은 예외 상황에 대한 테스트 코드를 생각하고 테스트 커버리지를 높이고, 테스트 코드의 가독성을 높이고, 아래 설명드릴 FIRST원칙을 지키며, 남들에게 도움이 되는 테스트코드를 작성하는 것 이라고 생각합니다..

 

 

 

 

3. 테스트 코드 팁

1. given, when, then

- 테스트 코드 작성시, 많은 곳에서 추천하는 코딩 스타일인데요, 어떤값이 주어지고(given), 무엇을 했을때(when), 어떤 값을 원한다(then)을 나누어 직관적으로 볼 수 있기 때문에, 테스트 코드의 가독성이 향상됩니다.

- 테스트 코드의 가독성이 중요한 또 다른 이유는, 테스트 코드가 문서로써의 역할을 하기도 하기 때문입니다. 테스트코드를 봄으로써, 해당 메소드를 작성한 개발자가 어떤의도로 만들었으며, 어떻게 동작하길 원하는지를 알 수있습니다.

 

 

2. 모든 response에 대한 테스트를 진행한다.

- api가(테스트대상) 조금이라도 수정될 경우, 테스트코드가 실패하게 됨으로써, 항상 올바른 테스트 코드를 유지할 수 있도록 돕습니다.

- api가(테스트대상) 변경되면, 테스트 코드역시 변경되어야 하는 것은 당연합니다.

- 테스트 코드는 커버리지가 높을 수록 좋습니다. 테스트 코드는, 정상적으로 작동하는 부분만을 테스트 하면 안됩니다, 테스트 코드는 실수나 오류를 발견하고 이를 줄이고 수정하기 위해 작성하는 것입니다.

 

 

3. F.I.R.S.T

FIRST는 아래의 용어들의 약자입니다. 하나씩 살펴보겠습니다.

 

Fast

단위 테스트는 가능한 빠르게 실행되어야 합니다. 실행함에 있어 너무 느려 테스트 실행을 꺼리게 된다면 잘못된 단위테스트입니다.

=> 하지만 Spring 테스트시 @SpringBootTest 어노테이션을 사용한다면, 해당 어플리케이션의 모든 빈을 IoC Container에 등록하고 테스트를 진행하기 때문에 테스트가 느려질 수 밖에 없습니다.

Independent

단위테스트는 객체의 상태, 메소드, 이전 테스트 상태, 다른 메소드의 결과등에 의존해서는 안됩니다. 따라서 단위테스트는 어떠한 순서로 실행하더라도 성공해야 합니다.

Repeatable

단위테스트는 반복 가능해야합니다. DB에 의존하는 테스트는 테스트 수행후 자동으로 롤백을 한다는 등의 별도 설정이 필요합니다.

Self-validating

단위테스트는 자체검증이 가능해야합니다. 테스트를 개발자가 직접 수동으로 확인할 필요 없이, Assert문 등에 의해 성공 여부가 결과로 나타나야합니다.

Timely

단위테스트를 통과하는 제품코드가 작성되기 바로전에 단위테스트를 작성해야합니다. TDD를 하고 있다면 적용이 되지만 그렇지 않을 수도 있습니다.