일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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
- 안드로이드 디자인패턴
- 단위테스트
- 코틀린
- Kotlin
- 제한함수
- 자료구조
- Android
- Di
- 디자인패턴
- 테스트의 장점
- 유닛테스트
- 깃
- Jetpack
- UnitTest
- dagger2
- rxjava
- git
- 파이썬
- 공격적 프로그래밍
- Room
- MVVM
- ViewModel
- mock
- 안드로이드
- Python
- Observable
- 코딩테스트
- 컴포즈
- compose
- 안정성
Archives
- Today
- Total
세상을 바꾸는 개발자
목은 훌륭한 도구? vs 사용하면 안 되는 것? 본문
목(Mock)
테스트 대상 시스템과 그 협력자 사이의 상호 작용을 검사하는 테스트 대역
테스트대역: 모든 유형의 비운영용 가짜 의존성을 설명하는 포괄적인 용어
테스트 대역
- 목(목, 스파이) : 외부로 나가는 상호작용을 모방하고 검사하는 데 도움
- 목 : 프레임워크의 도움을 받아 생성(가끔 직접 작성)
- 스파이 : 수동으로 작성
- 스텁(스텁, 더미, 페이크) : 내부로 들어오는 상호 작용을 모방하는 데 도움
- 더미 : 단순하고 하드코딩 된 값
- 스텁 : 시나리오마다 다른 값을 반환하게끔 구성할 수 있도록 해주는 완전한 의존성
- 페이크 : 대다수 목적에 부합하는 스텁(아직 존재하지 않는 의존성을 대체)
목과 스텁의 차이
- 목은 SUT와 관련 의존성을 간의 상호작용을 모방하고 검사하지만 스텁은 모방만 한다
- 목은 명령이고 스텁은 조회이다 (명령 조회 분리 원칙)
목은 스텁의 도구가 될 수도 있고 테스트 대역이 될 수 있다
스텁으로 상호 작용을 검증하지 말아야 한다. 스텁으로 상호 작용을 검사하면 과잉 명세가 발생한다
과잉 명세 : 최종결과가 아닌 사항을 검증하는 관행
공개 API , 비공개 API , 식별가능동작, 구현세부사항
식별가능동작: 도움이되는 연산을 노출, 계산수행, 부작용초례, 시스템의 상태를 노출
구현세부사항 : 위 사항이 아니라면 구현세부사항
잘 설계된 코드
- 식별동작 == 공개 API
- 세부사항이 잘 숨겨짐
API 를 잘 설계 한다면 단위 테스트도 자동으로 좋아진다
육각형 아키텍처 : 상호작용하는 애플리케이션의 집합
애플리케이션 계층, 도메인 계층
- 분리가 잘 이루어져야 한다
- 애플리케이션에서 도메인 계층으로 단방향이어야 한다
- 애플리케이션은 도메인 계층에 직접 연결 x, 공통 인터페이스를 통해 가능
시스템 내부통신, 시스템간의 통신
시스템 내부 통신 : 애플리케이션안에서 통신
시스템 간의 통신 : 애플리케이션이 외부 애플리케이션과 통신
목은 세부 구현사항과 관계가 없다
목은 시스템 내부 통신 보다는 시스템간의 통신에 사용하는 것이 좋다
혼자 단위테스트라는 책을 읽으면서 생각에 흐름대로 적은 글입니다..
참고한 책은 단위 테스트라는 책입니다. ( http://www.yes24.com/Product/Goods/104084175 )
'기타 > UnitTest' 카테고리의 다른 글
가치있는 테스트를 작성하는 방법 (0) | 2022.04.26 |
---|---|
출력기반, 상태기반, 통신기반의 테스트 스타일 (0) | 2022.04.25 |
좋은 단위 테스트의 4대요소(회귀방지, 리팩터링 내성, 빠른 피드백, 유지보수성) (0) | 2022.04.23 |
단위 테스트를 가능한 한 읽기 쉽게 만드는 방법 (1) | 2022.03.06 |
단위 테스트란 무엇일까? (런던파 vs 고전파) (0) | 2022.03.04 |
Comments