일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- UnitTest
- 안정성
- Android
- rxjava
- 안드로이드 디자인패턴
- 유닛테스트
- ViewModel
- 파이썬
- 단위테스트
- compose
- Python
- 테스트의 장점
- Jetpack
- 공격적 프로그래밍
- 제한함수
- 코딩테스트
- 자료구조
- git
- 디자인패턴
- dagger2
- mock
- 안드로이드
- 코틀린
- MVVM
- Di
- Room
- Kotlin
- 깃
- Observable
- 컴포즈
Archives
- Today
- Total
세상을 바꾸는 개발자
출력기반, 상태기반, 통신기반의 테스트 스타일 본문
하나의 테스트에서 3가지 스타일을 모두 사용이 가능
- 출력기반의 테스트 정의(가장 선호해야한다.)
- 입력을 넣고 출력을 검증하는 방식
- 전역상태나 내부 상태를 변경하지 않는 코드에만 적용되므로 반환 값만 검증하면 됨
- 함수형 프로그램에 뿌리를 두고있음(함수형으로 작성된 코드에만 적용가능)
- 테스트 대상 메서드에만 결합되므로 거짓 양성방지가 가장 우수(리팩터링 내성 가장우수)
- 유지비 가장 낮음
- 상태 기반 스타일 정의
- 작업이 완료된 후 시스템 상태를 확인하는 것(상태는 SUT, 협력자중 하나)
- 통신 기반 스타일 정의
- 목을 사용해서 테스트 대상 시스템과 협력자 간의 통신을 검증
- 유지비 가장 높음
고전파는 통신기반 스타일보다는 상태기반 런던파는 이와 반대 하지만 두분파는 출력 기반 테스트를 사용
함수형 아키텍처 vs 숨은 입출력
- 함수형 프로그래밍이란
- 수학적 함수(순수함수)를 사용한 프로그래밍
- 수학적함수란 숨은 입출력이 없는 함수(p.196)
- 목표 : 부작용을 완전히 제거하는 것이 아니라 비즈니스 로직을 처리하는 코드와 부작용을 일으키는 코드를 분리하는 것
- 숨은 입출력
- 부작용 : 메서드 시그니처에 표시되지않은 출력(숨어있음)
- 예외
- 내외부 상태에 대한 참조
비즈니스로직과 부작용을 분리
- 결정을 내리는 코드(함수형 코어)
- 부작용이 필요 없어서 수학적 함수를 사용해 작성
- 해당 결정에 따라 작용하는 코드(가변 셸)
- 수학적 함수에 의해 이뤄진 모든 결정을 가시적인 부분으로 변환
- 가능한 아무말도 하지 않아야한다.
함수형 아키텍처의 단점
- 항상 함수형 아키텍처를 이루기 힘듬
- 코드베이스가 커지고 성능에 영향을 미치면서 유지 보수성의 이점이 상쇄
- 유지보수성의 향상을 위해 성능을 희생시킨다.
- 모든 코드베이스를 함수형 아키텍처로 전환이 불가함 → 전략적으로 사용해야함
- (코드가 단순하거나 중요하지 않으면 별 효과x )
혼자 단위테스트라는 책을 읽으면서 생각에 흐름대로 적은 글입니다..
참고한 책은 단위 테스트라는 책입니다. ( http://www.yes24.com/Product/Goods/104084175 )
'기타 > UnitTest' 카테고리의 다른 글
통합테스트의 역할, 적용 시점, 다른 기법과의 의존 (1) | 2022.04.28 |
---|---|
가치있는 테스트를 작성하는 방법 (0) | 2022.04.26 |
목은 훌륭한 도구? vs 사용하면 안 되는 것? (0) | 2022.04.24 |
좋은 단위 테스트의 4대요소(회귀방지, 리팩터링 내성, 빠른 피드백, 유지보수성) (0) | 2022.04.23 |
단위 테스트를 가능한 한 읽기 쉽게 만드는 방법 (1) | 2022.03.06 |
Comments