일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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
- MVVM
- 깃
- 제한함수
- 안드로이드 디자인패턴
- 단위테스트
- ViewModel
- 컴포즈
- Android
- 테스트의 장점
- Di
- UnitTest
- compose
- 유닛테스트
- 파이썬
- Room
- Observable
- Python
- Kotlin
- 코딩테스트
- 공격적 프로그래밍
- git
- mock
- 코틀린
- 안정성
- dagger2
- 안드로이드
- Jetpack
- rxjava
- 디자인패턴
- 자료구조
Archives
- Today
- Total
세상을 바꾸는 개발자
단위 테스트를 가능한 한 읽기 쉽게 만드는 방법 본문
안녕하세요~ 헬창코딩 입니다.
참고한 책은 블라디미르 코리코프님이 지으신 UnitTesting란 책입니다.
오늘은 책의 3장의 내용을 정리하고 복습하려고 합니다.
주제
- (arrange, act, assert) AAA 패턴의 단위 테스트의 구조에 관한 설명
- 단위 테스트를 가능한 한 읽기 쉽게 만드는 방법
AAA 패턴
- 각 테스트를 준비, 실행, 검증 3가지로 단계로 나눌 수 있다.
- 모든 테스트가 단순하고 균일한 구조를 갖는 데 도움이 된다(일관성이 가장 큰 장점)
AAA 패턴의 단계
- 준비 구절
- 테스트의 대상 시스템과 해당 의존성을 원하는 상태로 만든다.
- 실행 구절
- 테스트 대상 시스템에서 메서드를 호출하고 준비된 의존성을 전달하고 출력값을 캡처한다.
- 검증 구절
- 결과를 검증한다. (결과는 반환 값이나 테스트 대상과 협력자의 최종상태, 협력자에 호출한 메서드 등으로 표시될 수 있다.)
Given-When-Then 패턴 : AAA와 유사한 패턴이고 테스트 구성 측면에서 차이는 없지만 유일한 차이점은
프로그래머가 아닌 사람에게 Given-When-Then 구조가 더 읽기 쉽다는 것임
(비기술자들과 공유하는 테스트에 좋음)
TDD를 실천할 때는 아직 기능이 어떻게 동작할지 충분히 알지 못한다.
따라서 먼저 기대하는 동작으로 윤곽을 잡은 다음, 이러한 기대에 부응하기 위한 시스템을 어떻게 개발할지 아는 것이 좋다. (하지만 테스트 전에 제품 코드를 작성한다면 이에 속하지 않는다)
단위테스트를 읽기 쉽게 하는 팁
- 여러 개의 준비 실행 코드 피하기
- 통합테스트가 아니라면 피하자! 필요하다면 리팩토링까지 해서 피하자!(통합테스트라도 지양하자)
- 만약 어쩔 수 없는 상황이라면 여러개의 테스트로 나누자
- 테스트 내 if 문 피하기
- 이것도 안티패턴이다.
- 단위테스트든 통합테스트든 분기가 없는 간단한 일련의 단계여야 한다.
- 테스트에 있어서 분기가 얻는 이점은 없다. 추가 유지비만 늘어난다.
- 테스트를 읽고 이해하는 것을 더욱더 어렵게 만든다.
- 테스트 구절의 크기에 따라 각기 다른 지침이 존재한다
- 준비 구절이 가장 큰 경우: 같은 테스트 클래스 내 비공개 메서드 또는 별도의 팩토리 클래스로 도출
- ex) 패턴 오브젝트 마더, 테스트 데이터 빌더
- 실행 구절이 한 줄 이상인 경우를 경계해야 한다. 2줄 이상인 경우 SUT의 공개 API에 문제가 있을 수 있음(절대 2줄 이상으로 두지 말라는 것은 아니지만 캡슈화 위반이 있을 수 있는지 살펴봐야 한다.)잠재적 모순으로부터 코드를 모호한 행위가 일어나지않도록 → 캡슐화
- 2줄 이상이면 모순이 생길 수 있음 → 불변위반
- 검증 구절에서 검증문검증구절이 너무 커지는 것은 경계해야한다.
- 단일 동작 단위는 여러결과를 낼 수 있고 하나의 테스트로 모든 결과를 평가하는 것이 좋다.
- 구절사이에 빈줄을 추가하거나 빈줄로 구분이 어려울 경우에만 주석을 추가하자(준비, 실행, 검증)
- 테스트 픽스처 초기화 코드는 생성자에 두지 말고 재사용할 수 있도록 만들어야한다.(팩토리 메서드 사용)
→ 재사용은 결합도록 낮게 만들어주고 가독성을 향상 시킨다.
- 엄격한 테스트 명명 정책을 시행하지말라
- 비개발자들에게 설명하는 것처럼 테스트 이름을 정해야한다.
- 밑줄을 사용해서 단어를 구분하자
- 테스트 대상 메서드 이름을 넣지 말아야한다.
- 매개변수화된 테스트를 위한 데이터 생성
- 단위 테스트의 프레임워크는 매개변수화된 테스트를 사용해서 유사한 테스트를 묶을 수 있는 기능을 제공
- → 테스트 양을 효과적으로 줄일 수 있음
- 단점: 비용이 발생, 사실파악의 어려움
- 점증문 라이브러리를 사용한 테스트 향상
- 테스트의 가독성을 높혀준다. (알아보기쉬운 영어문법으로 표현됨)
참고한 책
'기타 > UnitTest' 카테고리의 다른 글
출력기반, 상태기반, 통신기반의 테스트 스타일 (0) | 2022.04.25 |
---|---|
목은 훌륭한 도구? vs 사용하면 안 되는 것? (0) | 2022.04.24 |
좋은 단위 테스트의 4대요소(회귀방지, 리팩터링 내성, 빠른 피드백, 유지보수성) (0) | 2022.04.23 |
단위 테스트란 무엇일까? (런던파 vs 고전파) (0) | 2022.03.04 |
유닛테스트의 효과 및 목표 (0) | 2022.03.02 |
Comments