테스튼는 개발자 관점에서 애플리케이션 내부적으로 올바르게 작동하는지 확인하는 것이 아니라, 사용자 관점에서 애플리케이션 외부적으로 제대로 작동하는지 확인하는 것이 목표입니다.
단위 테스트는 개발자가 작성하며 개발자에게 유용합니다. 예를 들어 다음은 파보나치 수를 계산하는 fib 함수에 대한 단위 테스트로 앞에 있는 파보니치 숫자 5개를 제대로 구하는지 확인하는 테스트 입니다.
@Test
fun 'fib works correctly for the first 5 positions'(){
assertEquals(1, fib(0))
assertEquals(1, fib(1))
assertEquals(2, fib(2))
assertEquals(3, fib(3))
assertEquals(5, fib(4))
}
}단위 테스트는 일반적으로 다음과 같은 내용을 확인합니다.
- 일반적인 유스케이스 요소가 사용될 거라고 예상되는 일반적인 방법을 테스트합니다. 예를들어 앞의 코드처럼 함수로 간단하게 숫자 몇개를 테스트 합니다.
- 일반적인 오류 케이스와 잠재적인 문제 : 제대로 동작하지 않을 거라고 예상되는 일반적인 부분, 과거에 문제가 발생했던 부분 등을 테스트 합니다.
- 에지 케이스와 잘못된 아규먼트: Int의 경우 Int.MAX_VALUE를 사용하는 경우, nullable의 경우'null' 또는 null값으로 채워진 객체를 사용하는 경우를 의미 합니다. 또한 파보니치 수는 양의 정수로만 구할 수 있습니다. 음의 정수등을 넣으면 아규먼트 자체가 잘못된 것입니다. 이러한 경우를 테스트 할 수 있습니다.
단위 테스트는 개발자가 만들고 있는 요소가 제대로 작동하는지를 빠르게 피드백 해주므로 개발하는 동안에 큰 도움이 됩니다. 테스트는 계속해서 축적되므로, 희귀 테스트도 쉽습니다. 또한 수동으로 테스트하기 어려운 것들도 확인할 수 있습니다. TDD(Test Driven Development)라는 접근방식도 있습니다. TDD는 개발 전에 테스트를 먼저 작성하고 테스트를 통과시키는 것을 목적으로 하나하나 구현해 나가는 방식 입니다.
장점을 정리해보면
- 테스트가 잘 된 요소는 ㅅ신뢰할 수 있습니다. 요소를 시뢰할 수 있으므로 요소를 활용할 작업에 자신감이 생깁니다.
- 테스트가 잘 만들어져 있다면, 리첵터링하는 것이 두렵지 않습니다. 테스트가 있으므로 리펙터링했을 때 버그가 생기는지 쉽게 확인할 수 있습니다. 따라서 테스트를 잘 만든 프로그램은 코드가 점점 발전합니다. 반면 테스트가 없으면 실수로 오류를 일으킬 수 있다는 생각에 레거시 코드를 수정하려고 만지는 것을 두려워하게 됩니다.
- 수동으로 테스트하는 것보다 단위테스트로 확인하는 것이 빠릅니다. 바른 속도의 피드백 루프가 만들어지므로 개발의 전체적인 속도가 빨라지고 재미있습니다. 또한 버그를 빠릴 찾을 수 있으므로 버그를 수정하는 비용도 줄어듭니다.
- 단위 테스트를 만드는 데 시간이 걸립니다. 다만 정기적으로 좋은 단위 테스트는 '디버깅 시간'과 버그를 찾는 데 소모되는 시간을 줄여 줍니다. 또한 단위 테스트가 수동 테스트보드 훨씬 빠르므로 시간이 절약됩니다.
- 테스트를 활용할 수 있게 코드를 조정해야 합니다. 변경하기 어렵기는 하지만, 이러한 변경을 통해서 훌륭하고 잘 정립된 아키텍쳐를 사용하는 것이 강제됩니다.
- 좋은 단위 테스트를 만드는 작업이 꽤 어렵습니다. 남은 개발 과정에 대한 확실한 이해가 필요합니다. 잘못 만들어진 단위테스트는 득보다 실이 큽니다. 단위 테스트를 제대로 하려면, 올바르게 단위 테스트를 하는 방법을 배워야 합니다. 소프트웨어 테스팅 또는 테트 주도 개발과 관련된 내용을 이해해야 합니다.
단위테스트와 관련된 기술을 습득하고 다음과 같은 부분에 대해 단위 테스트하는 방법을 알아야 합니다.
- 복잡한 부분
- 계속해서 수정이 일어나고 리펙터링이 일어날 수 있는 부분
- 비즈니스 로직 부분
- 공용 API 부분
- 문제가 자주 발생하는 부분
- 수정해야 하는 프로덕션 버그
728x90