코틀린 스터디/이펙티브 코틀린

아이템10) 단위 테스트를 만들어라

막이86 2024. 2. 29. 14:12
728x90

이펙티브 코루틴을 요약한 내용입니다

  • 코드를 안전하게 만드는 가장 궁극적인 방법은 다양한 종류의 테스트를 하는 것
    • 이런 종류의 테스트는 사용자 관점에서 테스트
    • 개발자에게 유용하지만 충분하지는 않음
  • 개발시점에 빠른 피드백을 받기 위해서는
  • 피보나치 숫자 5개를 제대로 구하는지 확인하는 테스트
@Test
fun `fib works correnctly 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))
}
  • 단위 테스트에서 확인할 부분
    • 일반적인 유스 케이스: 요소가 사용될 거라고 예상되는 일반적인 방법을 테스트
      • ex) 함수로 간단한 숫자 몇 개를 테스트
    • 일반적인 오류 케이스: 제대로 동작하지 않을 거라고 예상되는 일반적인 부분
      • ex) 과거에 문제가 발생했던 부분
    • 에지 케이스와 잘못된 아규먼트: Int의 경우 Int.MAX_VALUE를 사용하는 경우, nullable의 경우 null 또는 null값으로 채워진 객체를 사요하는 경우
      • ex) 피보나치 함수에 음의 정수를 넣는 테스트
  • 단위 테스트는 개발자가 만들고 있는 요소가 제대로 동작하는지 빠르게 피드백을 줌
  • 계속해서 축적되므로, 회귀 테스트도 쉬움
  • 단위 테스트의 장점
    • 테스트가 잘 된 요소는 신뢰할 수 있음
    • 리팩터링하는 것이 두렵지 않음
    • 수동으로 테스트하는 것보다 단위 테스트로 확인하는 것이 빠름
  • 단위 테스트 단점
    • 단위 테스트를 만드는 데 시간이 걸림
      • 장기적으로는 디버깅 시간 및 버그를 찾는데 소모되는 시간을 줄여줌
      • 수동 테스트보다 빠르므로 시간 절약 가능
    • 테스트를 활용할 수 있게 코드를 조정해야 함
      • 변경을 통해 훌륭하고 잘 정립된 아키텍처를 사용하는 것이 강제 됨
    • 좋은 단위 테스트를 만드는 작업이 꽤 어려움
      • 잘못 만들어진 단위 테스트는 득보다 실이 큼
      • 소프트웨어 테스팅 또는 테스트 주도 개발과 관련된 내용을 이해해야 함
  • 중요한 코드라고 할 수 있는 부분에 대해 단위 테스트하는 방법을 알아야 함
    • 복잡한 부분
    • 계속해서 수정이 일어나고 리팩터링이 일어날 수 있는 부분
    • 비즈니스 로직 부분
    • 공용 API 부분
    • 문제가 자주 발생하는 부분
    • 수정해야 하는 프로덕션 버그

정리

  • 애플리케이션이 진짜로 올바르게 동작하는지 확인하는 테스트 필요
  • 테스트 중에 개발 과정에서 가장 효율적으로 활용할 수 있는 테스트는 단위 테스트
  • 비즈니스 애플리케이션 등에서는 최소한 몇 개라도 단위 테스트가 꼭 필요
728x90