[번역] DroidKaigi 2016 ~ 내가 테스트 써라고 말하는 아저씨가 된 경위와 그 과정에서 한 일
Feb 29, 2016. | By:
pluulove
본 포스팅은 droidkaigi-2016 을 기본으로 번역하여 작성했습니다
제 일본어 실력으로 인하여 오역이나 오타가 발생할 수 있습니다.
실제 발표내용에 해당하는 슬라이드와 슬라이드의 일본어 부분만 번역만 번역했다는 점 양해바랍니다.
1p
내가 테스트 쓰라고 말하는 아저씨가 된 경위와 그 과정에서 한 일
2p
자기소개
- kaido yuya
- 주식회사 Eureka
- 테스트 쓰라고 하는 아저씨 (신졸)
- Android는 2년
3p
주식회사 Eureka
- 자사 서비스의 기획 · 개발 · 운영
- 온라인 데이팅 서비스 : pairs
- 커플 전용 어플 : COUPLES
- 사원 수 : 85명
- IAC 그룹
4p
Android 버전을 담당 → COUPLES
6p
개요
- 납기를 우선으로 한 나머지 설계가 소홀히
- 당연히 테스트를 작성할 여유 따윈 없다
- 나중에 테스트를 작성하려 해도 적을 수 없다
- 테스트 가능한 설계로 하기 위해서 무엇을 했는가
7p
목차
- 테스트가 없으면 어떻게 괴로운가
- Couples의 설계
- 테스트 가능한 수준 높은 설계
- 테스트 방법 · 프레임워크
- 샘플 어플에서 테스트
- 테스트를 작성하는 문화를 만들기 위해서
- 정리
9p
Couples에서의 사례
- 방대한 테스트 케이스의 입력 확인
- 영향 범위 고려 실수에 의한 버그
- 테스트 케이스의 복잡화
10p
방대한 테스트 케이스의 입력 확인
- Couples은 꽤 기능이 많다
- 50페이지 이상의 Google Spreadsheet
- 릴리즈 전에 영향이 있는 테스트케이스를 입력하고 전부 확인
11p
괴롭다!!
12p
방대한 테스트 케이스의 입력 확인
- 입력하지 않으면 불가능한 테스트 케이스도 있다
- 하지만, 자동 테스트 가능할 것 같은 부분도 꽤 있다
13p
그 외 화면
- 프로필로 이동
- 즐겨찾기로 이동
- 히스토리로 이동
- etc…
자동화 가능하잖아
14p
영향 범위 고려 실수에 의한 버그
- iOS의 배포 후에 Android에 착수했기에, 당시는 빨리 릴리즈하는 것을 중시
- 파탄난 기반설계와 Copy&Paste 때문에 전혀 관계없는 부분에서 버그가 발생
- 배포 전에 전체 테스트 케이스를 포함하는 것은 현실적이지 안다
15p
테스트 케이스의 복잡화
- 테스트 케이스에 의존관계가 발생하기 시작
- 이 케이스 필요한 경우는 그 케이스도 하지 않으면 안되는
16p
각각의 문제점
- 방대한 테스트 케이스의 입력확인
- 영향 범위 고려 실수에 의한 버그
- 테스트 케이스의 복잡화
17p
아저씨는 이렇게 생각했다
18p
- 이대로는 유연적이지 않다
- 오히려 유지 보수 불가능하게 된다
- 하지만, 아직 맞출 수 있을거야
19p
그래, 테스트를 쓰자
20p
테스트 방침
- UI는 빈번히 변경이 있으므로, 비용적으로 맞지 않을 가능성이 있다
- 먼저 변경이 적은 백엔드부터 하자
- 백엔드
- 어디까지나 Android 어플내의 백엔드
- DB나 API 접근
22p
테스트를 못 적겠다
24p
현재 설계
25p
현재 설계
- 견고한 Activity/Fragment
- 정말로 놀랄 정도로 견고함
- 테스트를 쓰지는 못할망정 기능추가도 괴롭다
- 백엔드 클래스간의 의존관계가 복잡
- 테스트를 쓰기 어렵다
- MockServer로 바꿔치기가 어렵다
Pluu: 여기서 견고라고 표현한 것은 Activity/Fragment에 3000 라인 이상이 포함된 코드라고 생각하시면 됩니다.
26p
아저씨의 선택지
- 기존 백엔드에 직접 손을 가하다
- 새로운 백엔드를 만들어 전환
27p
아저씨의 결단
- 기존 백엔드에 직접 손을 가하다
- 의존관계가 복잡
- 테스트가 없는 상태에서 손을 가하는것이 무섭다
- 새로운 백엔드를 만들어 전환
- 의존관계를 말끔히 정리
- 테스트를 작성하면서 기능 단위로 차례로 교체함으로 리스크를 줄인다
29p
테스트 가능을 높이기 위해서는
- 각층의 역할이 명확
- CI 서버에 지속해서 테스트가 가능
30p
프론트 엔드 ↔ Model ↔ 백엔드
31p
백엔드
32p
백엔드
- 각층의 역할이 명확하게
- CI 서버상에서 지속해서 테스트할 수 있게
33p
프론트엔드
34p
- View-Model
- Model → Controller
- Controller → Model
- View → Controller
- Controller → View
35p
MVC
- 장점
- 단점
- Activity/Fragment가 View와 Controller의 성질을 가지기 때문에, 견고하게 되기 쉽다
36p
MVP
- View-Model
- Model → Presenter
- Presenter → Model
- View → Presenter
- Presenter → View
37p
MVP
- 장점
- 직무의 분리
- Activity/Fragment = View
- Presenter = Controller
- 단점
- 클래스 수가 많아진다
- 팀 개발이면 어느 정도 문서가 필요
38p
프론트엔드
- 여러 가지 아키택처가 존재하지만, 아직 개인적으로 마음에 드는 것이 없다
- 결국은 테스트를 적는 것이 목적이므로, 특정 아키택처에 구애될 필요는 없다
- 백엔드를 간결하게 하는 것으로 프론트도 어느 정도 간결하게 되므로 테스트를 쓸 수 있을 것 같다
40p
테스트 방법
- 유닛 테스트
- 메소드 단위로 로직의 타당성을 테스트 하는 것
- UI 테스트
41p
테스트 프레임워크
42p
JUnit4
- Testing Support Library
- 유닛 테스트를 위한 프레임워크
- 로직의 테스트만이라면 이걸로 충분
43p
Espresso
- Testing Support Library
- UI 동작도 포함한 테스트 작성을 할 수 있다
- 실제 단말로 테스트 실행
- 인간이 조작하는 것과 같은 시간이 걸린다
45p
Robolectric
- UI 동작을 포함한 테스트 작성을 할 수 있다
- 실제 단말이 요구되지 않는다
- 공식적으로는 API 21까지만 서포트하고 있지만, API 23에서도 사용할 수 있다.
47p
샘플 구현
48p
Contributor
49p
GithubDatabase
50p ~ 56p
GithubNetwork
57p ~ 58p
GithubDatabase의 테스트
59p
TestSubscriber
- RxJava 테스트용 클래스
- 이벤트를 기록해주는 편리한 클래스
- onNext(), onError(), onCompleted()에서 assert를 작성해도 괜찮지만,,,
60p ~ 61p
TestSubscriber
62p ~ 65p
GithubDatabase의 테스트
66p ~ 67p
GithubNetwork의 테스트
68p
MockWebServer
- square/okhttp/mockwebserver
- 이름대로 Web 서버의 Mock이 가능
- 신뢰하는 Square 제품
69p ~ 72p
MockWebServer
73p
Mockito
74p ~ 78p
메소드 호출 확인
79p ~ 82p
메소드 반환값의 Mock
83p ~ 87p
GithubNetwork 테스트
89p
테스트를 작성하는 문화를 만들기 위해서
- 주 1회 스터디를 개최
- Android 팀은 10명
- 테스트를 작성할 수 있는 환경을 만드는 것만으로는 불충분
- 솔직히 이것이 가장 중요
90p
스터디
- 아키택처에 대해서
- 일반적인 테스트에 대해서
- Android에서의 테스트에 대해서
- 테스트 작성시의 Tips
91p
아키택처에 대해서
- 새로운 아키택처의 개요
- 새로운 라이브러리
- Retrofit
- OkHttp
- RxJava
- Gson
92p
일반적인 테스트에 대해서
- 소프트웨어 테스트
- 화이트/블랙박스 테스트
- 동일값/경계값
- 명령/분기/조건 다수
93p
Android에서의 테스트에 대해서
- 테스트 프레임워크
- JUnit4
- Espresso
- Robolectric
94p
테스트 작성시의 Tips
- 테스트의 부작용
- Obserable 테스트 방법
- 비동기처리의 테스트
96p
정리
- 테스트가 없으면 어떻게 괴로운가
- 방대한 테스트 케이스로 인해 인적 자원 낭비나 예기치 못한 버그
- 기회손실
97p
정리
- Couples의 현재 설계
- Activity/Fragment가 견고하다
- 백엔드의 의존관계가 복잡
98p
정리
- 테스트하기 쉬운 수준 높은 설계
- UI는 빈번히 변경되므로, 우선은 백엔드부터 하자
- 데이터 취득 로직을 Activity/Fragment로부터 분리
- Android에 의존하지 않고 테스트할 수 있도록
99p
- 테스트 방법
- 테스트 프레임워크
- JUnit4
- Espresso
- Robolectric
100p
정리
- 샘플 어플에서의 테스트
- Github의 Contributors를 표시
- Database, Service의 테스트
101p
정리
- 테스트를 작성하는 문화를 만들기 위해서
- 주 1회로 스터디
- 테스트를 작성할 수 있는 환경을 만드는 것만으로는 불충분하며, 이것이 가장 중요할지도
102p
마지막으로
- 테스트가 목적이 되서는 안됨
편하게하고 싶다- 엔지니어는 태만해져야 하며
- 유익하게 업무시간을 쓰도록 된다면, 엔지니어도 사용자도 행복!
105p
보조자료
106p
ResponseUtil
107p ~ 108p
GithubRepository
comments powered by