Unit Test부터 UI Test까지!

코드의 품질에 관심을 갖기 시작하게 된 Unit test 입문기와, UI Automator2에 대한 간단한 소개

Transcript

1. Unit Test부터 UI Test까지 부현식
2. Who am I?
3. 부현식 컴퓨터 공학 전공 삼성전자 무선사업부 (2년차 개발자) Bixby2.0 Client 개발 안드로이드, TDD, 자동화, 블록체인 Github : boohyunsik Blog : boohyunsik.github.io
4. Contents 1. Unit test 와의 첫 만남? 2. Unit test 의 진가 3. UI Testing 까지!
5. Unit test 에 대한 편견?
6. 귀찮다. 그거 짤 시간이 어디있냐. 빌드할 때 자꾸 남의 TC가 죽어서 싫다. TC 짜는 법 배우기 귀찮다.
7. 대학생때의 나 객체 지향 프로그래밍..? 그거 먹는건가요.. 프로그램은 돌아가기만 하면 되지~ 어차피 과제내면 안 볼 코드들이야~ 대기업 가려면 알고리즘 문제 푸는게 우선이야!
8. Unit testing과의 첫 만남? 소프트웨어 공학 시간…
9. Example
10. Example
11. 이걸 굳이 왜…?
12. Unit testing의 진가 공모전
13. Retrofit 따릉이정보를 보여주는 Android app 제작 식당 정보를 받아오기 위해 Retrofit을 이용
14. But… Retrofit을 처음 써보는 상황 Rest API? 뭐지 그게…
15. But… Unit test는 머릿속에 존재도 하지 않음… 안드로이드 개발도 해본 경험이 별로..
16. How to test? Retrofit을 이용해서 축제 정보 받아오는 로직 구현 로그로 받아온 정보를 다 찍고
17. How to test? APK를 설치해서 데이터를 실제로 받아오는 곳까지 직접 들어가서 로그를 확인!
18. How to test? 또한 Rest API는 Postman을 이용하거나 Retrofit은 새로운 Java 프로젝트를 만들어서 테스트!
19. 매우 매우 귀찮고 비효율적인 것 같다…
20. Unit test를 활용해보자!
21. 간단한 배경지식… Mocking : 테스트용 가짜 객체를 만드는 것 Assert : 조건에 부합하지 않으면 프로그램을 종료함
22. Unit test를 활용해보자! Retrofit을 이용하여 따릉이 정보를 가져오는 메소드
23. 결과! 간단하게 유닛 테스트 작성
24. 메소드 단위로 실행 즉석에서 메소드 단위로 실행 가능!
25. 뭐가 좋은가? 굳이 App을 실행하여 테스트 할 필요가 없음 메소드 단위로 실행하여 따릉이 api를 잘 쓰고 있는지 간단하게 테스트 가능!
26. 이거 좀 쓸만한데…? (감이 오기 시작…)
27. 다른 부분에도 Unit test를 적용해보자!
28. 그러나 이미 프로젝트는 산으로…
29. Refactoring for Test Code !
30. 테스트를 방해하는 요소들 1. 복잡한 의존과 강한 결합 2. 덩치가 큰 메소드
31. 복잡한 의존과 강한 결합 객체끼리 직접 결합하고 있는 경우!
32. 복잡한 의존과 강한 결합 ToggleButton이 하나 있는 액티비티
33. Activity에 있는 ToggleButton이 눌려있는지 반환하는 기능을 제공하는 Example 클래스
34. 간단하게 만들어본 테스트 코드
35. @Before annotation이 붙은 함수는 각 테스트 함수 실행 전에 실행됩니다.
36. 이 테스트 함수는 isToggleSelectedInActivity가 반환하는 값을 출력합니다.
37. 테스트 실패입니다 ㅠ.ㅠ
38. 왜 실패할까…?
39. 강하게 결합하는 구조는 테스트하기 어렵다!
40. 이유는 많더라.. 1. 안드로이드 디바이스에 엮인 객체라던가 2. 의존하는 클래스가 또 다른 컴포넌트에 의존 한다던가 3. 서버 통신이나 인증 과정이 필요한 경우나…
41. Android Device Activity JVM Activity? 액티비티는 안드로이드 OS가 만들어줘야 의미를 갖지, 내 컴퓨터의 JVM 위에서는 의미가 없다!
42. 그리고 어찌어찌 안드로이드 의존을 잘 해결했더라도 이 함수는 정해진 값 만을 return하게 됨
43. 결합을 약하게!
44. 테스트 코드 상에서 실행하기 힘들었던 MainActivity를, 테스트용 View로 바꿀수 있다
45. 인터페이스로 구현
46. Example이 MainActivity를 MainView 인터페이스를 통해 의존하도록 변경!
47. 상황에 맞는 객체를 내 마음대로 주입할 수 있다. isToggleSelectedActivity가 true인 경우 isToggleSelectedActivity가 false인 경우
48. interface MainView 테스트 코드 상에서 실행하기 힘들었던 MainActivity를, 테스트용 View로 바꿀수 있다 True를 반환하는 Activity Example False를 반환하는 Activity Constructor
49. 이렇게 가짜 객체를 만드는 걸 Mocking 이라고 이해하면 될 것 같다!
50. 이런 경우… 메소드 안에서 Intent 객체를 새로 생성하는 상황
51. 마찬가지로 에러를 맛보게 됩니다…
52. Context, Intent, Bundle 처럼 안드로이드에 의존하는 객체들은 Mocking을 해주던지, build option을 바꿔줘야 함
53. 빌드 옵션을 바꾸어도 내가 원하는 대로 동작하지 않음!
54. Mockito등을 이용해 Mocking을 하더라도 활용할 수가 없다. (객체가 메소드 안에서 만들어지기 때문)
55. 어떻게 해결할까?
56. 의존성 주입(DI)를 적극적으로 활용하거나 Factory pattern 비스무리한 모양을 이용해보자!
57. 함수 Parameter로 주입 받는 경우
58. Factory 패턴을 흉내내서 만든 Injector (PowerMock을 이용하여 static class mocking 가능)
59. 그 외 Dagger나 Koin같은 DI library 사용도 고려할 수 있습니다.
60. 내가 만든 mock 객체를 주입해서 테스트 할 수 있다.
61. 1. 인터페이스와 추상이 어떤 효과를 갖는지 알겠다! 2. 다형성에서 말하는 갈아 끼운다가 어떤 뜻인지 알겠다! 3. 의존성 주입이 테스트에 어떤 영향을 미치는지 알겠다!
62. 덩치가 큰 메소드
63. …
64. 뭘 테스트 해야 하지…?
65. 쓰레드 시작하면서 토큰 정의
66. Connection 정의하면서 파라미터 추가 버퍼 생성
67. 받아온 데이터 Json 파싱
68. 액티비티 전환
69. Firebase 데이터 전송 및 Toast 띄우기
70. 이 메소드가 하는 일이 너무 많아서 테스트 해야 할 게 너무 많다!!
71. 메소드 크기를 작게 유지해야 테스트 하기 편하겠다!
72. Connection 생성해서 데이터 받아오는 메소드 -> 제대로 받아오는지 테스트
73. 받아온 Json 데이터를 파싱하는 메소드 -> 예제 데이터를 넣고 제대로 파싱하는지 테스트
74. 액티비티 전환 및 Toast 실행 메소드 -> 내가 의도한 인터페이스가 실행되는지 테스트
75. 앞서 설명한 것들을 전부 묶어서 Integration Test!
76. Unit test의 효과
77. 애매했던 객체 지향 프로그래밍의 개념들에 대한 이해 인터페이스와 다형성, DI에 대해!
78. 테스트 하기 좋은 코드에 대해 고민하기 시작
79. TDD, 개발 방법론, 소프트웨어 아키텍처
80. CI에서의 Test case 빌드 시 테스트 케이스를 모두 실행 내 수정사항으로 인해 다른 테스트 케이스가 실패한다면? 프로그램에 버그가 발생할 가능성이 있다는 것!
81. Open Source 에서의 Test case 코드를 보는 것 vs 테스트 코드를 보는 것
82. 유닛 테스트를 작성함으로써 코드의 품질을 높일 수 있다! (시작이 반이라고..)
83. UI Test 까지!
84. Bixby UI Test 많은 종류의 사용자 명령 … 어떻게 테스트 하지?
85. UI Automator2 외부에서 앱을 조작해주는 테스트 라이브러리 (Android Accessibility 이용)
86. 이렇게 컴포넌트를 쉽게 찾고
87. 이벤트도 쉽게 발생시킬 수 있다!
88. 또한 하드웨어 버튼 이벤트도 발생시킬 수 있다!
89. Device 객체를 만들고
90. Home 버튼을 누르고
91. Package 이름을 통해 앱을 찾는다.
92. 또한 패키지 이름을 통해 앱을 실행시킨다.
93. 앱이 실행될 때 까지 기다린다.
94. Resource ID를 기준으로 View를 찾고, 텍스트를 넣어준다.
95. Resource ID 기준으로 View를 찾고 클릭한다.
96. Resource ID가 “testToBeChanged” 인 View가 나타날 때 까지 기다린다.
97. View에 text가 의도한 결과와 같은지 비교한다.
98. 기계적으로 반복해야 하는 검증을 자동화 할 수 있다.
99. 날씨 알려줘, 맛집 알려줘, 알람 맞춰줘, …
100. 하드웨어 이벤트, 다양한 기준으로 View를 찾고 이벤트를 발생시킬 수 있는 강력한 라이브러리!
101. 꼭 한번 사용해보세요 :)
102. 감사합니다.