[Unit-Test] 하고 계신가요? 개발자 단위 테스트

안녕하세요. 많은 개발자들이 중요성은 알지만 하지 않거나 못하는 것이 있습니다. 바로 단위 테스트입니다. 하지 않는 이유로는 많은 이유를 듭니다.

• 비즈니스 로직에 집중하는 시간도 부족한데 무슨 테스트를 작성하는가?
• 이것도 나중에 유지보수가 되어져야하니 부담스럽다
• 귀찮다

저 또한 마찬가지로 막연하게 테스트를 작성하라고 했을 때는 귀찮음을 많이 느꼈습니다. 하지만 요즘은 스스로 테스트 코드 작성의 룰을 세우고 테스트 코드를 작성하고 있습니다.

오늘은 단위 테스트를 해야하는 이유에 대해서 공유드리도록하겠습니다.

테스트의 범위

테스트는 위의 이미지와 같이 5개의 범위로 나눌 수 있습니다.

단위 테스트를 제외한 나머지는 아래와 같이 정의되어집니다.

• 통합 테스트 : 여러 작업 단위가 연계된 워크플로우를 테스트 하기 위한 수단(객체 간, 서비스 간, 시스템 간)
• 기능 테스트 : 공개된 API의 가장 바깥쪽에 해당하는 코드 검사( Controller 호출, Security, http )
• 부하 테스트 : 주어진 단위 시간 동안 어플리케이션이 얼마나 많은 요청을 처리할 수 있는지 검사
• 인수 테스트 : 고객 또는 대리인이 정의되어진 모든 목적에 부합되는지 확인해보고자 하는 검사

그리고 아래는 개발 주기에 따른 테스트입니다.

개발 주기에 따른 Test

단위 테스트

단위 테스트는 테스트 유형에 따라 논리 단위 테스트, 통합 단위 테스트 등으로 나눌 수 있습니다.

• 논리 단위 테스트 : 한 메서드에 집중한 테스트로 mock이나 stub을 이용해 테스트 메서드의 경계를 제어할 수 있습니다.
• 통합 단위 테스트 : 실제 운영 환경(혹은 그 일부)에서 컴포넌트 간 연동에 치중한 테스트, 예를 들어 데이터베이스를 사용하는 코드라면 데이터베이스를 효과적으로 호출하는가를 테스트할 수 있습니다.

위에서 살펴보았던 테스트는 해당 코드를 작성한 개발자가 진행하기도 QA또는 고객이 직접 테스트하는 경우도 있습니다. 하지만 단위 테스트의 경우 해당 코드를 작성한 개발자가 진행하는것이 일반적입니다.

단위 테스트가 필요한 이유

그렇다면 위의 다른 테스트와는 별개로 단위 테스트를 개발자가 직접 진행해야하는 이유는 무엇일까요?

단위 테스트는 메서드 단위의 테스트로 어플리케이션이 기대한 대로 잘 동작함을 증명하고, 버그를 조기에 잡아내는 것을 기본 목적으로 합니다.

그렇다면 단위 테스트를 왜 해야하며 했을 때 어떤 이득이 있을 지 보도록 하겠습니다.

연관 컴포넌트의 제작이 완료되지 않더라도 코드 푸쉬 가능

큰 프로젝트에서는 여러 컴포넌트를 각각 개발하는 경우가 많습니다. 이때 해당 연관된 컴포넌트가 완성되지 않으면 내 코드가 정상동작하는지 알 방법이 없습니다. 따라서 연관된 컴포넌트가 다 완성되고 실제 연동을 해보고 나서야 완성됬다고 판단할 수 있으며 코드를 push 가능할 것입니다.

하지만 단위 테스트를 사용한다면 연관 컴포넌트가 개발되지 않더라도 개발이 마무리 됬다고 증명할 수 있습니다. 바로 mock을 이용하는 것입니다.  mock을 이용하여 API문서에 맞게 기대값을 설정하여 테스트한다면 외부 컴포넌트가 완성되지 않았더라도 본인의 컴포넌트만을 이용하여 검증할 수 있습니다.

단위 테스트 스위트를 이용하여 새로운 기능의 추가 및 기존 기능의 수정에 대해 이전 코드의 정상동작을 확인 가능

단위 테스트는 새로운 테스트를 만든다고 해서 이전 테스트가 없어지는 것이 아닙니다. 그리고 테스트 스위트를 이용하여 모든 테스트를 동시에 실행시킬 수 있습니다. 그렇기 때문에 새로운 기능의 추가 또는 이전 기능의 수정에 대해 기존 기능이 정상 동작하는지 판단 할 수 있는 근거가 됩니다.

Class 설계 변경에 대한 리펙토링이 일어날 때 정당성 부여 가능

리펙터링을 하가위해서는 기존의 코드가 망가지지 않는다는 것을 확신할 수 있어야 합니다. 단위 테스트는 리펙토링에 의해 기존의 코드가 망가지지 않는다는 것을 보장할 수 있습니다. 리펙토링 후 기존 로직이 동작하지 않아 테스트가 실패했다면 레펙토링을 진행함에 있어 로직 변경이 존재했다는 의미이기 때문입니다.

구현 코드의 품질 향상 기능

단위 테스트를 만들고 관리할 때는, 단위 테스트 자체도 주의 깊게 들여다보아야 합니다. 하나의 단위 테스트가 너무 길어지거나 복잡해지는 것은 대상 코드에서 bad smell이 나는 경우로, 이 순간 리펙터링이 필요합니다. 또는 하나의 테스트 메서드에서 너무 많은 기능을 수행하기 때문일 수도 있습니다. 이런 경우 역시 테스트 클래스 내의 리펙토링이 필요합니다.

구현 코드의 예제 소스 역할

단위 테스트는 API의 사용법을 보여주는 예제 역할을 할 수 있습니다. 또한 이 단위 테스트는 배포되는 코드와 일치하므로 다른 형태의 문서와 달리 항상 최신 상태로 유지된다는 이점도 있습니다.

마무리

오늘은 이렇게 단위 테스트를 했을 때의 이점에 대해서 알아보았습니다.

다들 귀찮더라도 기본적인 단위 테스트는 꼭 작성하는 것을 추천드립니다.

도움이 되셨다면 아래 광고한번 눌러주세요.

큰 도움이 됩니다.

감사합니다.

참조

JUnit in Action