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
'코틀린 스터디 > 이펙티브 코틀린' 카테고리의 다른 글
아이템12) 연산자 오버로드를 할 때는 의미에 맞게 사용하라 (0) | 2024.03.08 |
---|---|
아이템11) 가독성을 목표로 설계하라 (0) | 2024.03.05 |
아이템9) use를 사용하여 리소스를 닫아라 (0) | 2024.02.28 |
아이템8) 적절하게 null을 처리하라 (0) | 2024.02.23 |
아이템7) 결과 부족이 발생한 경우 null과 Failure를 사용하라 (0) | 2024.02.22 |