[이펙티브 코틀린] 아이템 10. 단위 테스트를 만들어라

코드를 안전하게 만드는 궁극적인 방법은 다양한 종류의 테스트를 하는 것이다.

이런 종류의 테스트는 개발자 관점에서 앱 내부적으로 올바르게 작동하는지 확인하는 게 아니라 사용자 관점에서 앱 외부적으로 제대로 작동하는지 확인하는 게 목표다. 이런 테스트는 개발자에게 유용하지만 충분하진 않다. 이것만으론 해당 요소가 올바르게 작동한다는 걸 완전하게 보증할 수는 없다. 또한 개발 시점에서 빠른 피드백을 받을 수 없다.

이런 문제를 해결하려면 단위 테스트가 필요하다. 이것은 개발자가 작성하며 개발자에게 유용하다.

 

단위 테스트는 일반적으로 아래 내용들을 확인한다.

 

• 일반적인 유스 케이스(happy path) : 요소가 사용될 거라 예상되는 일반적인 방법을 테스트한다. 앞의 코드처럼 함수로 간단한 숫자 몇 개를 테스트한다
• 일반적인 오류 케이스와 잠재적인 문제 : 제대로 동작하지 않을 거라고 예상되는 일반적인 부분, 과거에 문제가 있었던 부분 등을 테스트한다
• 엣지 케이스와 잘못된 아규먼트 : Int의 경우 Int.MAX_VALUE를 사용하는 경우, nullable의 경우 null 또는 null값으로 채워진 객체를 쓰는 경우를 의미한다. 또한 피보나치 수는 양의 정수로만 구할 수 있다. 음의 정수 등을 넣으면 아규먼트 자체가 잘못된 것이다. 이런 경우를 테스트할 수 있다

 

단위 테스트는 개발자가 만들고 있는 요소가 제대로 동작하는지를 빠르게 피드백해주므로 개발하는 동안 큰 도움이 된다.

테스트는 계속 축적되므로 회귀 테스트도 쉽다. 또한 수동 테스트하기 어려운 것들도 확인할 수 있다. TDD라는 접근 방식도 있다. TDD는 개발 전에 테스트를 먼저 작성하고 테스트를 통과시키는 걸 목적으로 하나하나 구현해 가는 방식이다.

단위 테스트의 장점을 정리하면 아래와 같다.

 

• 테스트가 잘 된 요소는 신뢰할 수 있다. 요소를 신뢰할 수 있으므로 요소를 활용한 작업에 자신감이 생긴다
• 테스트가 잘 만들어져 있다면 리팩터링하는 게 두렵지 않다. 테스트가 있으므로 리팩터링했을 때 버그가 생기는지 쉽게 확인할 수 있다. 따라서 테스트를 잘 만든 프로그램은 코드가 점점 발전한다. 반면 테스트가 없으면 실수로 오류를 일으킬 수도 있다는 생각에 레거시 코드를 수정하려고 만지는 걸 두려워하게 된다
• 수동 테스트하는 것보다 단위 테스트로 확인하는 게 빠르다. 빠른 속도의 피드백 루프가 만들어지므로 개발의 전체적인 속도가 빨라지고 재밌다. 버그를 빨리 찾을 수 있어 버그 수정 비용도 줄어든다

 

하지만 아래와 같은 단점도 있다.

 

• 단위 테스트를 만드는 데 시간이 걸린다. 다만 장기적으로 좋은 단위 테스트는 디버깅 시간과 버그를 찾는 데 소모되는 시간을 줄여준다. 또한 단위 테스트가 수동 테스트 또는 다른 종류의 테스트보다 훨씬 빨라서 시간이 절약된다
• 테스트를 활용할 수 있게 코드를 조정해야 한다. 변경하기 어렵지만 이런 변경을 통해서 잘 정립된 아키텍처를 쓰는 게 강제된다
• 좋은 단위 테스트를 만드는 작업이 꽤 어렵다. 남은 개발 과정에 대한 확실한 이해가 필요하다. 잘못 만들어진 단위 테스트는 득보다 실이 크다. 단위 테스트를 제대로 하려면 올바르게 단위 테스트를 하는 방법을 배워야 한다. 소프트웨어 테스팅 또는 TDD 관련 내용을 이해해야 한다

 

숙련된 코틀린 개발자가 되려면 단위 테스트 관련 기술을 습득하고 중요한 코드라고 할 수 있는 아래에 대해 단위 테스트하는 방법을 알고 있어야 한다.

 

• 복잡한 부분
• 계속 수정이 일어나고 리팩터링이 일어날 수 있는 부분
• 비즈니스 로직 부분
• 공용 API 부분
• 문제가 자주 발생하는 부분
• 수정해야 하는 프로덕션 환경에서의 버그