사실 코드를 안전하게 만드는 가장 궁극적인 방법은 다양한 종류의 테스트를 하는 것이다. 해당 코드가 올바르게 작동한다는 걸 보증하고 개발 시점에서의 빠른 피드백이 필요하면 단위 테스트를 하자.
단위 테스트
그럼 단위 테스트로 어떤 걸 테스트 하나? 일반적으로 다음과 같은 케이스들을 확인한다.
-
일반적인 유스 케이스 (= happy path)
-
일반적인 오류 케이스와 잠재적인 문제
-
에지 케이스와 잘못된 아규먼트
단위 테스트는 개발자가 만들고 있는 코드가 제대로 동작하는지 빠르게 피드백해주기 때문에 큰 도움이 된다.
심지어 이 테스트가 축적되면 회귀 테스트도 쉽다.
(TDD로 코드 자체를 구성할 수도 있다)
단위 테스트 장점은 아래와 같다.
-
테스트가 잘 된 코드는 신뢰할 수 있다.
-
테스트가 잘 만들어져 있다면, 리팩터링하는 것이 두렵지 않다. 버그가 생겼는지 쉽게 확인할 수 있기 때문이다.
-
수동으로 테스트하는 것보다 빠르다.
하지만 단점도 있다.
-
단위 테스트를 만드는 데 시간이 걸린다. 물론 장기적으로는
디버깅 시간과버그를 찾는 데 소모되는 시간을 줄여준다. -
테스트를 활용할 수 있게 코드를 수정해야 한다. 그래서 이런 변경을 통해 잘 정립된 아키텍처를 사용하도록 강제할 수 있다
-
좋은 단위 테스트를 만드는 것은 어렵다. 잘못 만들어진 단위 테스트는 득보다 실이 크다.
효과적인 단위 테스트를 하는 방법을 습득하고 단위 테스트를 위한 코드를 작성하는 것은 생각보다 어렵다.
숙련된 코틀린 개발자가 되려면, 단위 테스트와 관련된 기술을 습득하고, 중요한 코드라면 더욱 단위 테스트하는 방법을 알고 있어야 한다.
다음과 같은 부분들을 단위 테스트로 만들어서 관리해보자!
- 복잡하 부분
- 계속해서 수정이 일어나고 리팩터링이 일어날 수 있는 부분
- 비즈니스 로직 부분
- 공용 API 부분
- 문제가 자주 발생하는 부분
- 수정해야 하는 프로덕션 버그
우리의 프로그램은 올바르게 작동해야 한다. 그러므로 가장 중요한건 올바르게 작동하는게 진짜로 의도한대로 되는지 확인하는 것이다. 그게 바로 테스트고, 이를 가장 효율적으로 활용할 수 있는 테스트는 단위 테스트다.
최소한 몇 개라도 단위 테스트를 해보자!
