AW200: 안드로이드와 자바8, 프로젝트 테스트, 개발환경 세팅 공유 등

by Realm Korea

Apr 27 2016

Android Weekly는 매주 발행되는 안드로이드 뉴스레터입니다. 영어 기사를 정독할 시간이 없는 분을 위해 핵심 꼭지를 요약했습니다.

주간 안드로이드 뉴스를 요약해 드립니다. Android Weekly 200 원문도 읽어보세요.

Congratulations!

안드로이드 위클리가 200호가 발행되었습니다. 4년 반 정도의 시간이 흐르는 동안 약 40000명이 꾸준히 구독하면서 탄탄한 커뮤니티로 성장하고 있는 안드로이드 위클리인데요, 매주 소개되는 다양한 이슈를 Realm에서도 앞으로도 꾸준히 요약, 정리해서 소개해드리겠습니다.

안드로이드 개발에서 Java 8 사용 주의점 및 특징

최근 안드로이드 N프리뷰에서 발표한 새로운 특징들 중 Jack 컴플라이러를 통한 자바 8 서포트 내용이 포함되어 있습니다. 안드로이드 N프리뷰와 자바 8 (Java 8 in Android N Preview)에서는 실제로 안드로이드 개발자들이 어떻게 새로운 언어특징을 사용할 수 있을지 제시하고 있습니다. (참고로 이 글은 2016년도 3월 30일까지 유효한 정보로 작성되었으며 구글의 다음 릴리즈에서는 이 글에서 다루지 않는 새로운 특징이 포함될 수 있습니다!)

우선 개발자들은 자바8과 minSdkVersion의 관련성을 고려해서 선택적으로 자바8을 사용해야 합니다. 분류해보면 안드로이드 진저브레드(API 9)부터 그 이상은 Lamda Expression, java.util.function을 사용할 수 있고 안드로이드 N부터 그 이상은 Default/static interface methods, Repeatable annotations, Streams, Reflection APIs를 사용할 수 있습니다.
Jack 컴파일러로 언어 하위 호환성(backward compatibility)을 지원하는데 이 컴파일러는 javac, ProGuard, dex 기능을 사용가능케하는 것으로 다시 말하면 Jacoco나 Mockito와 같은 툴 또는 자바 바이트코드를 중재하는 것은 없음(현재까지는)을 의미합니다. 아마도 이어지는 릴리즈에서 이 문제가 해결되기를 바라고 있습니다.
모든 개발자들이 좋아하실만한 내용으로 Lamda expression과 관련된 utility APIs는 이벤트 리스너를 제공할 때 익명 내부 클래스를 대체하면서 코드 가독성을 높이는데 유용할 것으로 예상됩니다.
Default/static interface methods가 추가되면서 유틸리티를 위한 추가 클래스 양을 대폭 줄일 수 있겠습니다.
현재 프리뷰에서는 자바8의 Stream을 사용할 수 없지만, AOSP소스에 머지 된 것을 보면 다음 N프리뷰 또는 베타 릴리즈에서 사용할 수 있을 것으로 기대합니다.
공식매뉴얼에서 안드로이드 N프리뷰와 Java8으로 프로젝트를 생성하는지 제공하고 있으니 한 번 따라해 보세요! 주의하실 점은 N SDK발표에서 minSdkVersion으로 JellyBean이나 Kitkat을 사용할 수 있다고 되어있지만 안드로이드 N 프리뷰 targetSdkVersion은 API가 N보다 낮으면 동작하지 않습니다. 게다가 minSdkVersion을 23이하로 설정하면 Java8 코드는 동작하지 않습니다.

이런 개발 뉴스를 더 만나보세요

도전! 프로젝트 테스트

많은 소프트웨어 프로젝트에서 테스트는 상대적으로 무시되는 경향이 있습니다. 관련 문서는 없고 또 툴이나 프레임웍은 사용이 어렵고 적절한 테스팅을 구현한 오픈소스 코드를 찾는 것도 거의 불가능한 것을 보면 구글도 테스팅하는 것을 크게 장려하는 것처럼 보이지 않죠; 초급자를 위한 효과적인 안드로이드 테스트 전략 (A beginners guide to an effective Android testing strategy)를 보면서 그럼에도 불구하고 테스트는 중요한 이유와 종류 등 관련 내용 확인해보시죠~

테스트가 중요한 이유
1. 앱 피처에 대한 정확성을 체크할 수 있게 한다.(전문 개발자라면 QA팀에만 의존하지 않겠죠~)
2. 테스트하는 단위를 고민하면서 코드 베이스 디자인과 모듈성을 향상시킨다.
3. 새로운 기능을 구현하거나 리팩토링할 때 기존에 있는 것을 망가뜨리지 않음을 확인하고 안전하게 리팩토링할 수 있다.
테스트의 종류
1. UNIT test: 작고 독립적인 코드 테스트로 하나의 클래스 또는 인터페이스나 메소드 테스트가 이에 해당합니다. 안드로이드에서는 JUnit으로 JVM에서 로컬로 사용하거나(더 빠름!) 에뮬레이터 또는 실제 디바이스에서 테스트 할 수 있습니다.
2. Integration test: 로그인 기능같이 여러 개체가 같이 동작하는 기능도 테스트 가능합니다. UI 인스트럭셩 테스트로 Espresso나 Automation 테스트로 UI Automator를 사용할 수 있습니다.
앱 테스팅을 위한 아키텍쳐 플랫폼을 테스트하는 것은 어려운 일이지만 가장 흔한 방식은 MVP패턴을 이용하는 것입니다. 이 패턴으로 테스트하기에 쉬운 구조를 갖추는 것이죠. 전형적으로 Activity와 Fragment 뷰 레이어는 로직을 포함하지 않습니다. Presenter는 연결해주는 역할이고 Model이 아마도 테스트의 주 대상이 될 것입니다.
Test Pyramid 테스트의 대부분은 Unit test가 차지합니다. 왜냐하면 unit test는 테스트 하는 범위가 분명하고 구체적이기 때문에 문제가 발생한다면 쉽게 찾아서 처리할 수 있지만, 기능이나 UI test같은 Integration test는 상대적으로 문제되는 부분을 정확히 짚어내기 어려울 수 있습니다.

Espresso, JUnit, UIAutomator를 사용한 Unit test와 Integration test구현 내용이 이어지니 차근히 따라새보시면서 테스트 입문해보세요!!

꿀팁! : 전체 팀원과 세팅 공유하기

프로젝트 개발 중 새로운 팀원이 합류하고 개발 환경을 일일이 세팅하는 일은 분명히 까다롭고 불편한 일입니다. 좋은 방법은 아니지만 GitHub에서 PR을 열 때 보이는 CONTRIBUTING 파일을 제시하는 방법을 많이들 사용하실 겁니다. 그런데 문제는 모든 관련 README와 문서들을 읽지 않는 것, 그리고 읽더라고 잘못 해석하는 일이 항상 있다는 것이 문제입니다. 이 문제를 해결할 수 있는 팁! 전체 팀원과 세팅 공유하기 (Share the settings with the whole team)에서 편리하게 팀원들과 안드로이드 스튜디오 세팅을 공유하는 방법을 소개해드립니다.

cmd-alt-l(Windows와 Linux라면 ctrl-alt-l)을 누르면 IDE가 코드를 리포맷해주는 것 알고계시죠? IDE에서는 기본적으로 파일 템플릿과 라이브템플릿을 제공하고 있습니다. 만약 필요하다면 기존의 Hungarian 노테이션을 수정할 수 있습니다.
모든 룰과 세팅을 포함한 JAR파일을 만들어 import하는 방법도 가능합니다. 그런데 이 방법이라면 프로젝트별로 약간씩 다를 수 있는 컨벤션을 모두 고려할 수 없는점, 그리고 모두 최신파일을 설치하지 않으면 개인별 차이가 발생할 수 있는 단점이 있습니다.
IDEA/AS에 Settings Repository라는 것이 있습니다. IDE 세팅과 특정 레파지토리의 세팅을 동기화해줍니다! 다만 이 방법의 단점은 서비스를 위한 사용자 이름 등 모-든 것을 공유한다는 것입니다.
글 저자가 사용하는 방법은 위와 같이 .gitignore 파일을 사용하는 것입니다. 이를 커밋한 후 preference를 열어주세요. code style 섹션에서 manage버튼을 누르고 Default에서 원하는 스타일로 변경 후 copy to project버튼을 누르시면 됩니다! 그리고 나서 .idea폴더를 보면 많은 파일이 생겼을텐데요~ 파일명만 봐도 어떤 것인지 알 수 있을겁니다. 가장 중요한 것은 물론 codeStyleSettings.xml과 fileTemplates내용이겠죠~ (IDE가 VCS의 세팅을 오버라이드 할 수 체크해보세요!!)