GDG Korea Android 컨퍼런스를 다녀와서

계기

https://www.facebook.com/groups/gdg.korea.android/

보안 확인 필요

 

최근 gdg korea android라는 페이스북 그룹을 찾았다.

저번에 구글 IO Extened 2019를 참가했을 때, 주최했던 그 그룹이었다. 그래서 바로 가입 신청을 하고 눈팅을 하고 있었다.

 

주제가 테스트라 시험 컨셉을 잡으셨다고..

 

그러던 중 "안드로이드 테스트"에 관한 컨퍼런스가 열린다는 게시글이 올라왔고, 마침 테스트에 관심 있던 나는 바로 신청을 하기 위해서 festa를 열었다. 하지만... 게시글 올린 지 2시간 후였는데도, 벌써 매진이 되어있었다. 

 

아쉬워하며 개인적으로 테스트 공부를 진행하고 있는데 "추가 좌석을 마련해서 추가 인원을 받겠다"는 내용이었다. 나는 바로 티켓을 구매하고 친구들에게도 이 소식을 전했다.

 

그리고 8월 31일, 컨퍼런스를 들으러 친구와 함께 출발했다.

 

컨퍼런스

컨퍼런스는 총 5개의 세션으로 구성되어 있었고, 4개는 컨퍼런스 형식이고 1개는 안드로이드 탐구영역이라는 생소한 시간을 준비했다.

맨 아래는 매교시 정시 입실이라고 씌여있다.

김우섭 - 아장아장 안린이의 안드로이드 테스트 첫걸음

발표 자료 : http://bit.ly/아장아장테스트

 

 김우섭님은 필자가 최근에 뱅크셀러드 전화면접을 봤을 때 진행하신 분이라서 신기하다고 생각하고 있었고, 테스트 첫걸음이라는 주제가 마음에 들었다.

 

 내용은 평이했다. 테스트의 분류를 두 가지 관점에서 말씀하셨는데 한 가지 분류는 테스트의 신뢰성, 테스트 코스트에 관련된 분류, 또 다른 하나는 테스트가 실행되는 장소 기반 분류였다.

 

테스트 코스트 관련 분류

UI Test (인수 테스트)

• 실제로 최종 사용자의 행동을 검증하게 된다.
• 실제 사용자의 행위를 검증하므로 신뢰성이 높다.
• 하지만 인수 테스트 관리에 큰 비용이 든다.

 

Integration Test (통합 테스트)

• 모듈 간 상호 작용을 검증한다.
• 유닛 테스트만으로는 복잡한 소프트웨어가 동작한다고 확신할 수가 없다.
• 유닛 테스트보단 더 많은 비용이 들지만 심하진 않다.

 

Unit Test (유닛 테스트)

• 각 컴포넌트 및 기능 단위 동작을 검증한다.

테스트 실행 장소 분류

Local Test

• JVM상에서 돌아서 매우 빠르다.
• 안드로이드의 src/test 폴더에 있다.

 

Instrument Test

• 실제 안드로이드 기기에서 돈다.
• 안드로이드의 src/androidTest 폴더에 있다.

테스트를 하는 이유

 김우섭님은 테스트를 하는 이유에 대해 짧게 명시를 했다.

 

 소프트웨어는 태생적으로 복잡한 컴포넌트로 구성되고, 해당 컴포넌트들이 서로가 서로를 참조하며 그 복잡성을 더해간다. 이런 상황에서 프로그래머가 자신이 수정한 코드가 다른 컴포넌트의 동작을 망치지 않았다고 보장할 수 있는 방법이 뭘까? 아마도 신이 아닌 이상 알기 어려울 것이다. 그래서 우리는 소프트웨어가 정상적으로 동작하는 케이스를 테스트로 만들어서 불안 요소를 최소화할 수 있다.

 

 테스트 코드를 작성하면 어떻게 불안 요소를 최소화 할 수 있다는 걸까?

1. 결함을 사전에 발견할 수 있다, 실제 행동이 일어나기 전(QA를 하기 전) 개발 과정 중에 코드의 이상을 포착할 수 있다.
2. 문서로서 작동한다, 소스코드에 대한 문서로써 작동하며 작성자의 의도, 코드 사용법, 주의사항을 코드로 명시한다. 이를 이용해서 코드 리뷰 시 리뷰어가 작성자의 의도를 명확하게 파악해 작업 효율이 늘어난다.
3. 리팩터링에 대한 확신, 하나의 컴포넌트를 수정했을 때, side effect가 있다면 테스트가 깨질 것이다. 해당 테스트가 깨진 이유에 대해서 알아보고 테스트가 작동하게 컴포넌트 수정을 마치면 된다.
4. 더 나은 구조를 유도한다, 테스트 가능한 구조는, 컴포넌트를 강제로 외부 종속성과 분리시킨다. 종단을 추상적으로 구현하게끔 강조하고 test double을 사용해 테스트한다.

테스트 작성 베스트 프랙티스

• 전제 (given) / 행동 (when) / 결과 (then)의 흐름으로 테스트 케이스를 작성하는 습관을 기르자.
• 가능한 모든 케이스를 구현한다. 모든 state와 모든 분기를 테스트하면 완벽하다
  • 테스트 커버리지 툴을 사용해서 시각적으로 어떤 케이스를 다루고 안 다루었는지 알 수 있다고 한다. 
• 각 테스트 케이스는 독립적으로 구현한다. (junit에서는 @Before, @After 어노테이션을 사용하여 유지한다)

느낀 점

• 테스트 커버리지 툴 신기하다.
• 몽키 테스트가 뭐지? 

 

김탁열 - JVM상에서 적절한 통합 테스트 하기, 스마트오더 안드로이드 개발기

 

 다음으로 발표하신 분은 우아한 형제들의 김탁열님이었다. 회사에서 혼자 작업하는 새로운 프로젝트를 시작하며, TDD 개발을 사용해 개발한 경험을 발표하셨다.

 

왜 테스트 코드를 초반부터 작성하기로 하였나

• 새롭게 시작하는 서비스를 개발하는 단계였다.
• 비즈니스의 변경 가능성이 높았다.
• 빠르게 개발해야 하는 상황이었다.
• 혼자 개발하는 환경이었다. (개인적인 생각으로 회사 차원에서 일인데 혼자 일하게 되면, 든든한 아군이 필요한데 이게 테스트 케이스 일듯)
• 테스트 코드를 작성하는 게 재밌어 보였다.

 김탁열님은 unit test는 너무 세세한 영역이고, 가능한 전체에 가까운 영역을 커버하고 싶었기 때문에 배제하였다고 한다.

 또한 ui test는 전체를 커버하는 영역이지만 과정이 매우 느려, 프로젝트에 적용하기 시간이 부족하다고 판단하였다.

 따라서 통합 테스트를 기반으로 TDD를 진행하였다.

 

테스트 전략

• JVM상에서 추상적인 UI를 테스트 하자. (UI를 하나의 종단으로 취급하면 된다.)
• 관심이 아닌 객체(이를 종단에 해당하는 클래스라고 하자)는 test double(mock, spy, fake 등 가짜 객체)로 만든다.
• 시나리오 기반으로 테스트 케이스를 작성한다.
• given / when / then을 지켜서 테스트 케이스를 작성하자.

느낀 점

 김탁열님의 코드를 보고 느낀 점은 이 사람은 코드 짜는 재미를 아시는 분이라는 생각이 들었다. 몇 가지 필자에게 인사이트를 주신 말을 적어 보겠다.

• 테스트는 작성자의 의도를 전달하는 것이다.
• 그러니 테스트 코드를 작성할 땐 가독성을 중요하게 생각하자.
• 테스트는 상태와 행위를 검증하는 것이다.

 재밌게 느낀 점은 탁열님이 개발 언어로 kotlin을 고른 이유인데, kotlin extenstion을 사용하여 가독성 높은 테스트 작성하는데 많은 도움이 되었다고 한다.

 

권태환 - QA에서 직접 UI 테스트 하기 위한 작업을 해보았다

 예전에 이분 기술 블로그를 참조해서 MVP 패턴을 공부하던 생각이 났다.

 

 QA팀이 개발하는 앱의 UI 테스트를 자동화했으면 좋겠다는 생각을 했으나. QA팀이 안드로이드 코드를 읽을 수 없어서 UI Test 프레임워크를 만든 과정을 컨퍼런스 화 하였다.

 

프레임워크 만들 때 사용할 것

• kotlin : java보다 가독성 높은 코드를 작성하여 QA팀에서 쉽게 코딩 가능하도록 구성하려고 선택하였다.
• android espresso recorder : 자동으로 UI 테스트를 만들어주는 안드로이드 스튜디오 지원 기능, 하지만 아직 버그가 많다.
• UI Automator : 프레임 워크를 만들 때 핵심적으로 사용하신 것 하드웨어 관련 함수를 호출할 수 있고, id가 아니라 다양한 기준으로 ui를 검색하고 검증할 수 있다.

비동기 응답을 개선하여 테스트 가능하도록 구성하도록 하자

 

UI 테스트는 너무 비싸고, 디자인 변경 시에 테스트를 전부 리팩터링 해야 하는 문제가 발생한다. 따라서 UI 테스트까지 가기 전 통합 테스트를 좀 열심히 하자

 

느낀 점

 android espresso recorder라는 기능은 신기해 보인다. 아직 베타에 가까운 기능인 것 마냥 버그가 많지만 일단 신기함.

 ui automator에 대해서 알아보고 싶어 졌다.

 

 UI 테스트를 알아보기 위해서 노력하기보다 통합 테스트를 잘하는 법을 더 많이 알아보자.

 

부현식 - 유닛 테스트 입문과 UI 테스트까지

 테린이 입장에서 테스트를 왜 해야 하고 하면 뭘 얻을 수 있는지 로드맵을 설명해 주 섰다.

 

Test를 하며 깨닫는 것들

• 인터페이스와 추상이 어떤 효과를 갖는지 알겠다.
• 다형성에서 말하는 갈아 끼운다가 어떤 뜻인지 알겠다.
• 의존성 주입이 테스트에 어떤 영향을 미치는지 알겠다.

느낀 점

 현식님이 테스트하면서 느끼신 점들이 나와 비슷하다고 생각했다. 막연한 객체지향에 대한 개념들이 테스트 코드 작성 시에 명확하게 와 닿는다. 

 물론 나는 객체지향에 관련된 내용을 아키텍처 공부이후 코끼리 코 더듬듯 알아갔다면, 살짝 테스트 공부에서 아키텍쳐 공부로 이어지는 흐름이 일반적인 흐름 같다고 생각했다.

느낀 점

 테스트 코드 가독성에 대해서 많은 생각을 하게 되었고, 최근에 관심 있게 읽고 있는 Clean Architecture의 내용의 원리를 이해하는데 도움이 많이 된 거 같다.

 테스트 커버리지 툴, UIAutomator, Kotlin Extenstion을 활용한 테스트 코드 가독성의 증가 등 새롭게 배우고 싶고 적용해보고 싶은 많은 주제를 알 수 있었다.

 

 안드로이드 공부의 어려움이 두 가지로 나뉘어 있다고 생각했다. Android 프레임워크를 배우는데 오는 어려움 / 프로그램을 만드는 것 자체에서 오는 어려움, 이 중 테스트 작성법은 프로그램을 만드는 어려움을 해소시켜주는 좋은 방법이라고 생각했다. TDD라는 게 어떤 종류의 프로그래밍이든 더 좋은 구조를 만들기 위해 필요하다고 판단했기 때문이다.