[Test] 테스트 코드를 왜 작성해야할까?

 

배경

회사에서 테스트 코드를 작성하면서 문득 테스트 코드를 왜 작성해야하는가에 대한 생각을 하게되었습니다. 많은 블로그에서 테스트 코드를 잘 작성하면 로직이 잘 동작하는지 빠르게 확인할 수 있고, 여러 예외 케이스들도 확인할 수 있다 등 여러 장점에 대해서 설명을 하고 있습니다.

 

 오늘은 제가 테스트 코드를 작성하면서 개인적으로 테스트 코드를 작성하면 어떤 이점이 있는지 얘기해보려고 합니다.  제가 여기서 다루는 테스트 코드는 Unite Test 를 의미합니다.

 

 

해당 기능 빠르게 확인

 테스트 코드를 통해서 기능을 쉽게 확인할 수 있습니다. 기능이라면 해당 로직에 어떤 값이 들어왔을 때 어떻게 동작하는지를 파악할 수 있다는 뜻입니다.

 java spring boot를 기준으로 보겠습니다. 보통 spring boot로 프로젝트를 하면 다음과 같이 계층 구조로 분리하여 코드를 개발합니다.

 Test code 없이 Service Layer, 서비스 로직을 확인하려면 Presentation layer(controller)에서 값을 넘겨주었을 때 제대로 동작하는지 확인을 해야합니다. 로직이 복잡해서 해당 로직에 값이 잘 들어가는지 확인을 세세히 하려고 하면 debug 모드로 값들을 하나씩 확인해봐야 합니다. Service Layer만 해도 controller에 요청을 보내야하는데 Data Access layer의 로직을 확인하려고 하면 두 번의 layer를 통과해야합니다. 또한 중간에 에러가 발생하면 Data access layer만 테스트하려고 하는 목적을 달성하기 어렵습니다.

 

 Controller를 테스트 코드 없이 직접 테스트 하려고 하는 경우에 실제 Client에서 요청을 날려보거나, api 호출을 할 수 있는 Postman으로 직접 요청을 보내거나 swagger를 이용해서 요청을 보낼 수 있습니다. 그러나 해당 api 요청을 매번 호출하여 테스트 하는 것은 번거롭습니다.

 Unit test를 통해서 해당 Layer만 테스트해 볼 수 있어 빠르게 해당 로직이 원하는대로 작동하는지 확인할 수 있습니다. 다른 Layer의 로직을 실행시켜야 할 경우 Mock을 이용해서 원하는대로 Stubbing할 수 있습니다.

 

 Test code를 이용해서 해당 기능을 확인하기 위해 테스트 코드 작성 시 성공하는 케이스와 실패하는 케이스를 예외 없이 전부 다 작성하는 편입니다. 실패 케이스가 10개가 넘더라도 해당 케이스를 다 작성해주어 예외 케이스가 발생하지 않게 하고 있습니다. 작성을 하다보면 사소한 파라미터의 차이로 테스트 메서드를 또 작성해야하는게 여간 귀찮은 일이 아닙니다. 이런 경우에는 @Parameterized Test를 사용하면 됩니다. 해당 기능에 관련해서는 추후에 다시 정리하겠습니다.

 

 

코드 품질 개선

 테스트 코드를 작성하다 보면 코드가 중복으로 들어가 있거나 해당 로직이 필요없을 수 있다고 느끼는 경우가 종종 있습니다. 처음 코드를 작성할 때 코드를 완벽하게 작성할 수 있으면 당연히 좋지만 그럴 수 없는 상황이 존재하고 완벽하게 코드를 짜는 경우가 드뭅니다. 혼자하는 프로젝트가 아닌 회사의 업무는 코드를 자그만치 몇 백줄을 작성해야하는 경우도 있고 개발기한이 촉박한 경우가 많습니다. 이럴 경우 테스트 코드를 통해서 코드 품질을 개선할 수 있습니다.

 

 중복이나 필요없는 로직뿐만 아니라 테스트 코드를 작성하면서 모든 성공 케이스 및 예외 케이스를 작성하면서 해당 로직의 필요성(내가 의도하는대로 동작하는지) 및 어떻게 개선을 하면 되는지도 알 수 있습니다.

 

 

리팩토링 용이

 코드를 처음부터 클린하게 작성을 하면 리팩토링이 필요가 없습니다. 하지만 로직 등 변경 사항이 많아 개발 시간이 촉박한 경우가 많습니다. 이러한 경우 에자일적으로 동작하는 소프트웨어 위주로 생각을 하여 어떻게든 동작하게만 코드를 작성하곤 합니다. 동작하는 소프트웨어를 만들고 추후에 리팩토링을 진행합니다.

 

 리팩토링에 용이하다는 장점은 테스트 코드를 엄청 꼼꼼하게 작성했을 때 해당이 된다고 생각합니다. 현재 코드에서는 해당 로직의 테스트 코드가 항상 성공하고 있다고 가정했을 때 리팩토링 시에도 테스트 코드가 항상 성공해야합니다.

 

 코드를 리팩토링할 때 로직이 실제로 예전과 같이 동작을 할까라는 걱정을 많이 하곤 했습니다. 꼼꼼하게 작성된 테스트코드가 있으면 리팩토링을 부분부분 할 때마다 테스트 코드를 실행시켜보고 잘 동작하는지 확인만 하면됩니다. 이러한 이점으로 인해 Spring boot 코드를 리팩토링 전에 테스트 코드를 꼼꼼하게 작성을 하고 있습니다. 

 

 

코드 이해도 증가

 회사에서 내가 직접 작성한 코드가 아닌데 테스트 코드를 작성해야하는 경우가 있습니다.

 처음에는 다른 사람이 짠 로직의 테스트 코드를 짜는게 나한테 무슨 도움이 있을까 의문이 들었습니다. 로직을 충분히 이해하고 테스트 코드를 작성해야 했기에 당연히 테스트 코드 작성 속도가 느렸습니다. 테스트 코드를 다 작성하고 난 후에 로직에 대한 이해도가 증가하였습니다. 테스트 코드 없이도 원래 코드만 보고 이해할 수도 있지만 테스트 코드를 작성하면서 더 세세하게 이해할 수 있었습니다.

 

 다른 사람이 짠 로직의 테스트 코드를 짤 때 단점도 존재했습니다. 어떤 의도로 해당 코드를 작성하는지를 잘 몰랐기에 코드를 작성한 개발자 분께 여쭤봐야했고 직접 작성한 코드의 테스트 코드보다는 테스트 코드를 기계적으로 짜는 느낌이 들었습니다.

 

 

마무리...

 신입이였을 때 테스트 코드 필요성을 글로만 알고 있었지만 막상 테스트 코드를 작성할 때는 기계적으로 작성을 하였습니다. 1년이 지난 지금 테스트 코드가 왜 필요한지 어떤 장점이 있는지 생각을 하면서 전보다 꼼꼼하고 효율적으로 테스트 코드를 작성하고 있습니다. 

이 글을 시작으로 앞으로 테스트 코드를 직접 작성할 때 어떻게 작성을 했는지 적어보려고 합니다.