[컨퍼런스] 안드로이드 탐구영역

2019.09.01

컨퍼런스를 다니며 기억보단 기록을하고자 합니다.

 

---

 

안녕하세요 이번에는 안드로이드 탐구영역에 다녀왔습니다.

2019.08.31 안드로이드 탐구영역

우선 이번행사는 안드로이드 테스트관련 주제로 배달의 민족을 만든 우아한형제들 작은집에서 진행된 컨퍼런스입니다.

위 사진에서 보시는바와 같이 수능의 시험지를 연상케하는 컨셉으로 컨퍼런스가 진행되었는데요.

컨퍼런스장에 입장하면서 받은 컴퓨터용사인펜!! 이때부터 심상치않은 분위기..

세션순서또한 교시로 표현였고, 컨퍼런스장소도 시험장소를 떠올리게하는 분위기였습니다. (과탐 시험치던 옛날생각....🤣)

그럼 어떤 내용으로 발표가 진행되었는지 하나씩 알아 보겠습니다.

 

0교시 - KeyNote (강경완 <우아한형제들>)

1교시 - 아장아장 안린이의 안드로이드 테스트 첫걸음 (김우섭<뱅크샐러드>)

2교시 - JVM상에서 적절한 통합테스트 하기(김탁열<우아한형제들>)

3교시 - QA에서 직접 UI테스트를 해보았다(권태환<카카오페이>)

4교시 - 유닛테스트 입문과 UI테스트까지(부현식<삼성전자>)

5교시 - 안드로이드 탐구영역(테스트퀴즈)

 

1교시 - 아장아장 안린이의 안드로이드테스트 첫걸음 - 김우섭(뱅크샐러드)

🖍1교시답게 아장아장 첫 기본개념부터 왜하는 가? 에대해 발표를 해주셨습니다. 그리고 주의해야할 점과 베스트 프랙티스와 앞으로의 고민 거리 까지 같이 해보면 좋을것 같다는 마지막 말로 발표를 마무리 해주셨습니다.

 

테스팅 피라미드

1. 기본개념

• 단위테스트(Unit Test)

  - 각 컴포넌트 및 단위의 동작을 검증

• 통합테스트(Integration Test)

  - 각 모듈간의 상호작용을 검증

• UI 테스트

  - 실제 유저가 보는 화면을 기준으로 하는 테스트

2. 테스트, 왜 하는가?

• 결함을 사전에 발견
  - 실제 행동이 일어나지 않더라도 개발과정에 포착 가능

• 문서로서 작용
  - 작성자의 의도, 사용법, 주의사항 등이 드러나게되어있음

• 실제 행동이 일어나지 않더라도 개발과정에 포착 가능
  - 작성자의 의도, 사용법, 주의사항 등이 드러나게되어있음

• 리팩토링에 대한 확신
  -이전 동작이 변경되지 않았음을 담보할 수 있는 장치

• 더 나은 구조를 유도
  - 역할 분담 및 관심사의 분리등, 테스트가 어렵다면 나쁜 징조라는 증거

3. 주의점/Best Practice
로컬에서 테스트를 돌리면 , 안드로이드 코드는 전부 예외를 뱉음
로컬테스트 : 맥이나 컴퓨터환경에서 진행
인스트루먼트 테스트 : 안드로이드 환경에서 진행

우회방법

• 모키토를 이용하는법 (모킹)
• Robolectirc 으로 구현을 주입하는 방법
• 인스트루먼티드 테스트로 돌리는 방법
• 안드로이드드 플랫폼 디펜던시는 걷어내고 테스트하기
• 적절한 assertion

2교시 - JVM상에서 적절한 통합테스트하기 - 김탁열(우아한 형제들)

🖍예제코드를 많이 작성하여 발표에 보여주셔서 "아 저런식으로 짜면되는구나" 싶었습니다. 코드예시가 있어 이해 하기 좀더 편했던 발표 였습니다.

 

1 용어논쟁

• 단위테스트
  - 코드의 잘정의된 부분을 격리한다는 의미에서 격리 테스트

• 통합 테스트
  - 더큰 세밀도에 포함되는 테스트로 단위나 컴포넌트

• 시스템 테스트
  - 전체 시스템을 검증

2 테스트 코드를 작성하자

• 시간이 지나도 동작이 바뀌지 않았음을 확인할 수 있다
• 잦은 리팩토링의 두려움을 없앨 수 있다
• 내가 짠 코드도 시간이 지나면 디테일한 배경이 기억나지 않는다
• 사용 시나리오를 기록하고 기획과 구현 의도를 코드보다 쉽고 빠르게 파악할 수 있다
• 저수준 설계의 방향을 알려준다
• 코드 한줄을 수정 하더라도 빠르게 피드백을 받을 수 있다
• 버그를 하나라도 QA 보다 먼저 알 수 있는 기회이다
• 코드 품질 향상에 이용 가능한 모든 방법 중에 가장 유용하다
• 버그를 잡는게 아니라 예방차원 노력할수 있다.

3 어떻게 작성할 것인가?

• 가능한 전체에 가까운 영역을 커버하고 싶다
• UI 테스트는 접근이 쉽지만 과정이 느리다
• 당장 모든 클래스의 단위 테스트부터 작성하기에는 여유가 없을 것 같다
• 단위 테스트의 목은 커버리지의 구멍을 만든다
• 단위 테스트, 컴포넌트 테스트가 중요하지만 QA가 오류를 찾지 못하리라는 확신을 가지려면 상위 계층 테스트가 필요하다
• Business rules are the reason a software system exists
  - Critical business rules
  - Application-specific business rules

4 전략

• 종단 간 사용성을 보여주는 적절한 상위 테스트를 작성하자
• 실제 단위나 컴포넌트, 모듈들이 조합되어 실행되게하자
• 유닛보다 더 상위 계층 테스트 일수록 유닛테스트에서 목을 통해 형성될 수 있는 구멍을 막을 수 있다
• 프레임워크나 느린 요소는 테스트 영역에서 제외하자
• 그래서 결론은 JVM 상에서 통합테스트를 하자
• 어렵고 디테일한 UI 상태 검증보다 되도록 추상적인 행위로 검증하자
• 화면 단위로 작성하고 범위를 벗어나거나 연동에 대한 시나리오는 추상적인 수준으로 하자
• 실제 UI 의 로직을 가능한 얇게 구성하여 JVM 상에서 테스트 영역을 늘리자

5 이점

• JVM상에서 빠른 디버깅이 가능하다
• 완벽한 TDD는 아니더라도 어느정도의 TDD가 가능하다
• 통합테스트를 기반으로 핵심 비즈니스 룰에 대한 시나리오실행과 검증을 실시간으로 체험해 볼수있다.
• 현실적이고 구체적인 문제도 미리 만나 볼수있다.

6 디버깅

• 실제 레스트API 호출을 호출하면서도 설치 구동과정없이 필요없어 비즈니스 룰에 대한 렌더링 및 디버깅에도 빠른 접근이 가능해진다.

3교시 - 좀더쉬운 UI테스트를 하기위한 작업을 해보았다. - 권태환(카카오페이)

🖍직접 QA팀과 부딪히며 테스트코드를 개발했던 경험을 공유 해주셨습니다. 

 

1 Tools
Language : Koltin
UI Test : Android Espresso
UI Test : Ui Automator
Best : Espresso Recorder

2 Espresso Recorder

• Android에서 제공한다.
• 녹화 하듯 테스트 케이스를 만들 수 있다.

3 Espresso Recoder 문제점

• 데이터를 다 불러오지 못할 경우 즉시 오류 발생 => 해결하려면 강제로 sleep을 추가해야함
• 기기가 달라지면 즉시 오류 발생 가능

4 어떻게 접근하는게 좋을까?

• 직접 라이브러리 제작
  - 메인 : UiAutomator
  - 보조 : Espresso
  - 언어 : Kotlin

5 UiAutomator 선택이유

• 화면에서 보이는 텍스트를 찾기 가능

• 클릭할 수 있는 형태를 만들 수 있다.

• 시스템 알림도 닫을 수 있다.(권한체크)

• 시스템도 컨트롤 가능(홈으로 갔다가 돌아오기...)

• 앱에서의 조건(최초약관동의, 최초 권한설정)

  6 UiAutomator 문제점

• 요구사항에 따른 주기적 업데이트 필요

• 텍스트가 없으면 테스트케이스 추가가 어렵다

• Espresso 이용해 풀어야 한다.

• Thread.sleep 이용으로 정확하지 않음

7 Thread.sleep 개선

• Coroutine Channel이용

8 성공적이지는 않다.

• 텍스트가 아닌 버튼에 대해서는 별도로 개발을 필요로 한다,.
• 스크롤에 대한 처리도 필요하다.
• 밀접하게 필요한 테스트케이스 필요항 값들을 처리 햐줘야한다.
• 대응이 어렵다

4교시 - 유닛테스트 입문과 UI테스트까지 - 부현식(삼성전자)

🖍직접 학부생때부터 느낀 테스트코드에 생각들은 발표해주셨습니다. 예전에 느끼셨던 감정과 생각들이 현재의 저와 비슷한 감정에 많은 공감과 이해가 쉬웠던 발표 였습니다. 꾸준히 노력해서 좋은 개발자가 되고 싶습니다.

 

1 Unit Test와의 첫만남

• Unit Test에 대한 편견
  - 귀찮다.
  - 짤시간이 어딨냐
  - 과제 내면 안볼코드
  - 이걸 굳이왜

2 Unit Test의 진가

• 공모전
• How to Test?
• 간단한 배경지식
  - Mocking : 테스트용 가짜 객체를 만드는 것
  - Assert : 조건에 부합하지 않으면 프로그램을 종료함
• 즉석에서 메소드 단위로 실행가능
• 뭐가 좋은가?
  - 굳이 앱을 실행하여 테스트할 필요 없음
  - 간단하게 테스트 가능
• 테스트를 방해하는 코드들
  - 복잡한 의존과 강한 결합 : 객체끼리 직접 결합 하고 있는 경우
  - 덩치가 큰 메소드
• 테스트 실패 이유
  - 안드로이드 디바이스에 엮인 객체
  - 의존하는 클래스가 또 다른 컴포넌트에 의존 한다던가
  - 서버통신이나 인증이 필요한 경우
  - 액티비티는 안드로이드 OS가 만들어 줘야 의미를 갖지 내 컴퓨터의 JVM위에서는 의미 없다.
• UnitTest의 효과
  - 애매 했던 객체 지향 프로그래밍의 개념들에 대한 이해
  - 인터페이스와 다형성 DI에 대한 이해

3 UI Test 까지

• UI Automator2 : 외부에서 앱을 조작해주는 테스트용 라이브러리
• 기계적으로 반복해야하는 검증을 자동화 할 수 있다.

 

5교시 - 안드로이드 탐구영역

마지막 5교시 안드로이드 탐구영역에서는 정말 시험지를 나눠주셨습니다...ㅎㅎ 테스트 코드와 관련된 문제를 내주셨고, 관련 문제를 푼팀에게는 사은품이 있었습니다. (저희조에서는 저는 아무것도 못했지만 팀원분들의 엄청난 실력덕분에 스벅1만원..쿠폰에 티셔츠까지... 감사합니다!!) 아직 저는 갈길이 먼것 같습니다. 꾸준히 노력해야겠습니다.👨‍💻

 

마치며

최근에 좋은기회에 TDD기반으로 Nodejs 강의를 들어보면서 TDD에 대한 관심을 가지게 되었고, 최근 회사의 큰 웹프로젝트를 테스팅 해보면서 테스트코드에 대한 필요성을 절실히 느끼고 있는 시점에 Android Test코드 컨퍼런스를 참석하게 되어 앞으로 꾸준히 코드를 리팩토링하며 테스트코드에 대한 공부를 이어나가볼 생각입니다. 아주 유익한 컨퍼런스 였습니다. 이후 테스팅과련한 포스팅으로 찾아 오겠습니다.!!😉 아참 TDD기반 Nodejs강의를 해주신 Chris님 정말 감사드립니다.ㅎㅎ

 

 

감사합니다.

❤️

Love YourSelf