일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Observable
- Room
- Android
- MVVM
- 단위테스트
- 코딩테스트
- Jetpack
- 자료구조
- ViewModel
- 공격적 프로그래밍
- UnitTest
- Kotlin
- git
- Di
- 컴포즈
- 안드로이드
- mock
- 안정성
- 제한함수
- 디자인패턴
- Python
- rxjava
- compose
- 깃
- 유닛테스트
- dagger2
- 코틀린
- 안드로이드 디자인패턴
- 테스트의 장점
- 파이썬
- Today
- Total
세상을 바꾸는 개발자
단위 테스트란 무엇일까? (런던파 vs 고전파) 본문
안녕하세요~ 헬창코딩 입니다.
오늘은 유닛테스트를 공부하면서 중요했던 부분과 생각했던 부분을 생각나는 대로 끄적여 보려고 합니다!! (단순 복습용)
참고한 책은 블라디미르 코리코프님이 지으신 UnitTesting란 책입니다.
저도 안드로이드 개발을 하면서 단위테스트란 말은 수도 없이 들어봤습니다.
그때마다 단위 테스트는 그냥 버그 및 에러 검증을 위해 테스트 코드를 작성해서 테스트하면 것 이라고만 알고 있었습니다.
이게 틀린 말은 아니긴합니다만 어떻게 작성해야 하고 어떻게 테스트를 해야 하는지는 솔직히 잘 몰랐습니다.
그래서 공부를 하게 되었는데요
오늘은 2장의 내용을 되돌아볼까 합니다
2장에서는 단위 테스트의 정의와 3가지 속성을 말하고 있습니다.
- 작은 단위로 검증 한다.
- 빠르게 수행한다.
- 격리된 방식으로 처리하는 자동화된 테스트 방식이다.
이게 작은 단위, 빠르게, 하지만 격리된 방식으로 처리한다는 게 무슨 말일까요??
여기서 3번째 격리된 방식으로 처리한다는 의미에서 고전파와 런던파의 근원적 차이가 나타남
단위 테스트의 접근 방법은 뚜렷하게 2가지로 나눌 수 있다고 합니다.
고전파와 런던 파의 특성을 정리하자면
- 고전파
- 모든 사람이 테스트와 주도 개발에 원론적으로 접근하는 방식
- 동작 단위의 테스트 방식
- 고품질의 테스트를 만들고 지속 가능한 성장을 달성하는데 더 적합
- 런던파
- 하나의 클래스가 다른 클래스 또는 여러 개의 클래스에 의존하면 이 모든 의존성을 테스트 대역으로 대체하는 방식(테스트 대상의 협력자를 제거하는 방식)
- 목을 사용하는 테스트는 고전적인 테스트보다 불안정한 경향이 있음(취약성)
- 입자성이 좋다
- 한 번에 한 클래스만 확인한다.
- TDD 형식으로 이루어진다.
- 과잉 명세
- 고전 스타일에 비해서 테스트가 구현에 더 자주 결합
- 테스트는 코드 단위가 아니라 동작 단위를 검증해야 하지만 런던 파는 아님(모순)
이렇게 고전파와 런던 파의 장점과 단점이 나타나는데요
뚜렷한 차이를 보자면
격리 주체 (고전파 - 단위 테스트, 런던 파 - 단위)
단위의 크기 (고전파 - 단일클래스 또는 클래스 세트, 런던파 -단일클래스)
테스트 대역 사용 대상(고전파 - 공유 의존성, 런던파 - 불변 의존성 및 모든 의존성)
이러한 차이가 난다고 합니다. 여기서 공유 의존성 이라는 말이 나오게 되는데 의존성이 무엇일까요?
의존성의 분류
- 공유의존성 : 내부 상태는 모든 자동화된 테스트에서 공유한다. 예) 데이터베이스
- 변경 가능한 비공개 의존성 : 클래스 내부에서 사용하는 인스턴스 예) 책에서 말하는 store 객체
- 변경 불가능한 비공개 의존성 : 값 객체 예) 상수
공유 의존성과 프로세스 외부 의존성
→ 비슷한 말 같지만 다름
→ 싱글턴은 공유 의존성에 속하지만 프로세스 외부 의존성에 속하지 않음
→ 데이터베이스는 공유 의존성도 속하고 프로세스 외부 의존성에도 속한다.
→ 읽기 전용 AP서비스는 프로세스 외부 의존성에만 속함
이 책에서 말하는 고전파와 런던 파가 어떤 것이고 어떠한 장점과 단점이 있는지는 알겠지만
어떤 것을 사용해서 내가 개발하는 프로젝트에 적용할지는 조금 더 생각을 해봐야 할 것 같습니다.
런던파를 사용하면 Mock을 사용해서 의존관계의 클래스를 임의로 정의를 하고 테스트를 할 수 있어서 어디서 문제가 되고 어디서 에러 및 버그가 있는지 쉽게 알 수 있긴 하지만 작은 단위 하나하나 테스트를 해야 하기 때문에 불필요한 테스트 코드가 많아질 것 같네요.
고전파를 사용을 했을 때는 전체적인 앱의 흐름을 알 수는 있지만 작은 단위부터 테스트를 해나가야 하고 코드 단위로 테스트를 하기보다는 기능 단위로 테스트를 하기 때문에 코드가 많아지면 어떤 클래스에서 에러가 및 버그가 발생하는지 찾기 힘들 것 같기도 합니다..
아니면 적절하게 섞어서 사용해도 되지 않을까 쉽네요!! 좀 더 공부를 해야 할 것 같습니다.
'기타 > UnitTest' 카테고리의 다른 글
출력기반, 상태기반, 통신기반의 테스트 스타일 (0) | 2022.04.25 |
---|---|
목은 훌륭한 도구? vs 사용하면 안 되는 것? (0) | 2022.04.24 |
좋은 단위 테스트의 4대요소(회귀방지, 리팩터링 내성, 빠른 피드백, 유지보수성) (0) | 2022.04.23 |
단위 테스트를 가능한 한 읽기 쉽게 만드는 방법 (1) | 2022.03.06 |
유닛테스트의 효과 및 목표 (0) | 2022.03.02 |