JY-Dev Tech Blog

Android(안드로이드) - Fragment 교체

JY-Dev — Mon, 16 Nov 2020 11:57:17 +0900

[OverView]

오늘은 Fragment 교체하는 방법에 대해 알려드리겠습니다.

[Code]

일단 Fragmnet를 교체하려면 FragmentTransaction이 필요합니다. 그래서 FragmnetManager에 있는 beginTransaction()을 통해 가져와 보도록 하겠습니다.

val fragmentTransaction = supportFragmentManager.beginTransaction()

이렇게 가져오면 FragmentTransaction안에 있는 함수인 replace를 호출해 바꿔줄 View와 Fragment를 선택해주도록 합시다.

// replace(your view , fragment)
fragmentTransaction.replace(R.id.frameLayout, fragmentList[position]).commitAllowingStateLoss()

그다음에 commitAllowingStateLoss를 통해 commit 해주도록 합시다. 이렇게 하시면 Fragment가 교체가 됩니다.

Android(안드로이드) - BottomNavigationView disable shifting mode

JY-Dev — Wed, 11 Nov 2020 22:27:10 +0900

[OverView]

머터리얼 디자인에있는 BottomNavigationView를 사용할때 자동적으로 Shifting 애니메이션이 생깁니다.

이 애니메이션이 필요가 없는경우에 제거방법에 대해 알려드리겠습니다.

[xml]

<com.google.android.material.bottomnavigation.BottomNavigationView
        android:id="@+id/bottom_navigation"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        app:labelVisibilityMode="labeled"
        app:menu="@menu/main_navigation_items"/>

app:labelVisibilityMode="labeled" 이것만 추가하시면 애니메이션을 제거할 수 있습니다.

[참고]

https://stackoverflow.com/questions/40176244/how-to-disable-bottomnavigationview-shift-mode

How to disable BottomNavigationView shift mode?

BottomNavigationView doesn't show menu's title that are inactive. How to show titles of all menu elements in bottomNavigationBar? The problem is that in my case shown only title of element that is

stackoverflow.com

안드로이드(Android) - Navigation 사용법

JY-Dev — Mon, 9 Nov 2020 13:28:28 +0900

[OverView]

이번에는 Navigation에 대해 알려드리겠습니다.

Navigation는 iOS개발에서 사용하는 스토리보드와 흡사합니다. Fragment간의 플로우를 시각적으로 볼수 있다는 특징이 있어 앱 플로우를 보거나 할때 유용하게 쓰일 수 있습니다.

[Navigation 구성요소]

Navigation Graph : 모든 Navigation 관련 정보가 하나의 중심 위치에 모여 있는 XML 리소스입니다. 단순히 말해 사용자가 앱에서 갈 수 있는 모든 플로우를 보여주고 앱내의 Fragment를 한눈에 확인 할 수 있습니다.
NavHost : Navigation Graph에서 대상을 표시하는 빈 컨테이너입니다. 대상 구성요소에는 프래그먼트 대상을 표시하는 기본 NavHost 구현인 NavHostFragment가 포함 됩니다.
NavController : NavHost에서 App Navigation을 관리하는 객체입니다. NavController는 사용자가 앱 내에서 이동할 때 NavHost에서 대상 콘텐츠의 전환을 조종하는 역활을 합니다.

Navigation Graph에서 특정 경로를 따라 이동할지, 특정 대상으로 직접 이동할지 NavController에게 전달하고 NavController가 NavHost에 적절한 대상을 표시해주는 방식입니다.

[장점]

프래그먼트의 트렌젝션 처리.
올바르게 Up과 Back동작을 처리.
화면전환에 대한 표준화된 애니메이션 리소스.
딥 링크 구현 및 처리를 쉽게 할 수 있다.
Bottom Navigation과 같은 요소들을 최소한의 추가작업으로 구현.
Safe Args - 대상사이에서 데이터를 탐색하고 전달할때 안정성을 제공하는 Graph 플러그인.
ViewModel - Navigation Graph에 대한 ViewModel을 확인해 그래프 대상 사이에 UI 관련 데이터를 공유.

[build.gradle]

   // Feature module Support
    implementation "androidx.navigation:navigation-dynamic-features-fragment:$nav_version"

    // Testing Navigation
    androidTestImplementation "androidx.navigation:navigation-testing:$nav_version"

    // Jetpack Compose Integration
    implementation "androidx.navigation:navigation-compose:1.0.0-alpha01"

3가지 라이브러리를 추가해주도록 합시다.

[Create Navigation Graph]

Project 창에서 res 디렉터리를 마우스 오른쪽 버튼으로 클릭하고 New > Android Resource File을 선택합니다. New Resource File 대화상자가 나타납니다.
File name 필드에 'nav_graph'와 같은 이름을 입력합니다.
Resource type 드롭다운 목록에서 Navigation을 선택한 후 OK를 클릭합니다.

제대로 완료 하셨다면 이런 창이 뜨게 됩니다.

일단 테스트를 위해 Fragment 2개를 생성해주도록 합시다 저는 fragment_blank 와 fragment_blank2라는 Fragment를 만들어 주었습니다.

[nav_graph.xml]

<?xml version="1.0" encoding="utf-8"?>
<navigation xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/nav_graph">


    <fragment
        android:id="@+id/blankFragment"
        android:name="com.jydev.navicontrollex.BlankFragment"
        android:label="fragment_blank"
        tools:layout="@layout/fragment_blank">
    </fragment>

    <fragment
        android:id="@+id/blankFragment02"
        android:name="com.jydev.navicontrollex.BlankFragment2"
        android:label="fragment_blank2"
        tools:layout="@layout/fragment_blank2"/>
</navigation>

id는 편한대로 설정하면되고 name에는 그 Fragment의 이름을 넣어줘야합니다. 그리고 tools:layout에는 그 Fragment의 layout을 지정해 주도록 합시다. (label은 선택사항)

그렇게 되면 Design탭에 들어가게되면 이런식으로 화면상에 Frament 2개가 생성이 됩니다.

왼쪽 하단에 있는 Component Tree에서 Start Destination을 지정해줄 수 있는데 이건 처음에 표시해줄 Fragment를 설정해 줍니다. 만약 Start Destination지정을 안해주면 에러가 발생하게 되니깐 꼭 지정해주면됩니다.

Start Destination을 지정해줄 Fragmemt에 우클릭 후 Set as Start Destination을 클릭해주면 선택한 Fragment에 Start Destination 지정이 됩니다.

이렇게 nav_graph에서 Fragment를 선택해주면 오른쪽 중앙에 파란색 원이 생기는데 이걸 드래그해서 다른 Fragment에 연결을 해주게 되면 다른 Fragment에 대한 Action을 지정 해줄 수 있습니다. 또한 Componet Tree에서 Action을 지정해줄 Fragment에 우클릭 후 Add Action을 통해 Action을 지정해 줄 수 있습니다.

이 Action을 통해 이동할 Fragment를 지정하거나 Data를 넘겨줄 수 있습니다.

화살표가 생기게 되는데 이는 Action을 나타냅니다.

화살표를 클릭하여 작업을 강조표시합니다. 다음 속성은 Attributes 패널에 표시됩니다.

Type 필드에는 '작업'이 포함됩니다.
ID 필드에는 작업의 ID가 포함됩니다.
Destination 필드에는 대상 프래그먼트 또는 활동의 ID가 포함됩니다.

Attributes에서 Animation을 설정해주거나 Launch Options를 설정 등등 여러가지 Action에한 설정을 해주실 수 있습니다.

다 완료가 되었다면 이 nav_graph를 표시해줄 Activity에서 FragmnentContainerView를 통해 이 graph를 보여 줄 수 있습니다.

[activity_main.xml]

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <androidx.fragment.app.FragmentContainerView
        android:id="@+id/nav_host_fragment"
        android:name="androidx.navigation.fragment.NavHostFragment"
        android:layout_width="0dp"
        android:layout_height="0dp"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintBottom_toBottomOf="parent"
        app:defaultNavHost="true"
        app:navGraph="@navigation/nav_graph" />


</androidx.constraintlayout.widget.ConstraintLayout>

다음 내용을 참고하세요.

android:name 속성은 NavHost 구현의 클래스 이름을 포함합니다.
app:navGraph 속성은 NavHostFragment를 탐색 그래프와 연결합니다. 탐색 그래프는 사용자가 이동할 수 있는 이 NavHostFragment의 모든 대상을 지정합니다.
app:defaultNavHost="true" 속성을 사용하면 NavHostFragment가 시스템 뒤로 버튼을 가로챕니다. 하나의 NavHost만 기본값으로 지정할 수 있습니다. 동일한 레이아웃에 여러 호스트가 있다면(예: 창이 2개인 레이아웃) 한 호스트만 기본 NavHost로 지정해야 합니다.

또한 다음과 같은 방법으로 Layout Editor를 사용하여 NavHostFragment를 활동에 추가할 수 있습니다.

프로젝트 파일 목록에서 활동의 레이아웃 XML 파일을 더블클릭하여 Layout Editor에서 엽니다.
Palette 창 내에서 Containers 카테고리를 선택하거나 'NavHostFragment'를 검색합니다.
활동으로 NavHostFragment 뷰를 드래그합니다.
다음으로, 표시되는 Navigation Graphs 대화상자에서 해당 탐색 그래프를 선택하여 이 NavHostFragment와 연결한 후 OK를 클릭합니다.

대상으로 이동하는 것은 NavHost 내에서 앱 탐색을 관리하는 객체인 NavController를 사용하여 실행됩니다. 각 NavHost에는 해당하는 자체 NavController가 있습니다. 다음 메서드 중 하나를 사용하여 NavController를 검색할 수 있습니다.

androidx.navigation | Android 개발자 | Android Developers

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates. Last updated 2020-07-22 UTC.

developer.android.com

FragmentContainerView를 사용하여 NavHostFragment를 만들 때 또는 FragmentTransaction을 통해 NavHostFragment를 활동에 수동으로 추가할 경우 Navigation.findNavController(Activity, @IdRes int)를 통해 활동의 onCreate()에서 NavController를 검색하려고 하면 실패합니다. 대신 NavHostFragment에서 직접 NavController를 검색해야 합니다.

val navHostFragment = supportFragmentManager.findFragmentById(R.id.nav_host_fragment) as NavHostFragment
val navController = navHostFragment.navController

[Safe Args]

대상 간 이동을 위해 Safe Args Gradle 플러그인을 사용하는 것이 좋습니다. 이 플러그인은 대상 간 유형 안전 탐색 및 인수 전달을 사용 설정하는 간단한 객체 및 빌더 클래스를 생성합니다.

[설명]

Safe Args를 사용 설정하면 생성된 코드에 정의한 작업의 클래스 및 메서드와 각 발신 및 수신 대상에 상응하는 클래스가 포함됩니다.

Safe Args는 작업이 발생하는 각 대상의 클래스를 생성합니다. 생성된 클래스 이름은 발신 대상 클래스 이름에 'Directions'를 붙입니다. 예를 들어, 발신 대상 이름이 SpecifyAmountFragment라면 생성된 클래스 이름은 SpecifyAmountFragmentDirections가 됩니다.

생성된 클래스에는 발신 대상에서 정의한 각 작업의 정적 메서드가 포함됩니다. 이 메서드는 정의된 모든 작업매개변수 를 인수로 사용하고 navigate()에 직접 전달할 수 있는 Navdirections객체를 반환합니다.

[build.gradle]

dependencies {
        classpath "com.android.tools.build:gradle:4.1.0"
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
        
        //Navigation Controller
        def nav_version = "2.3.1"
        classpath "androidx.navigation:navigation-safe-args-gradle-plugin:$nav_version"
    }

build 그래들에 의존성을 추가해줍시다.

plugins {
    id 'com.android.application'
    id 'kotlin-android'
    id 'androidx.navigation.safeargs.kotlin'
}

플러그인을 추가 해줍시다.

※ AndroidX 이전에 따라 gradle.properties파일에 android.useAndroidX=true가 있어야 합니다.

Safe Args를 사용하게 되면 Action을 지정해준 Fragment이름 + Directions이라는 클래스가 자동으로 생성됩니다.

그래서 생성된 BlankFragmentDirections에서 Action을 호출해 NavController로 그 액션을 수행해주면 됩니다.

button.setOnClickListener {
            val action = BlankFragmentDirections.actionBlankFragmentToBlankFragment022()
            it.findNavController().navigate(action)
        }

이렇게 되면 Button을 클릭하면 생성해 두었던 Action인 actionBlankFragmentToBlankFragment022()을 NavController를 통해 호출합니다.

Android(안드로이드) - What is Appium?

JY-Dev — Thu, 29 Oct 2020 10:49:07 +0900

[OverView]

UI 자동화 테스트를 찾아보다가 Appium 이란 프레임워크를 알게 되었습니다.

그래서 Appium에 대한 설명을 간략하게 정리하려고 합니다.

[Appium]

Appium은 오픈 소스, 크로스 플랫폼 자동화 테스트 도구입니다. 네이티브, 하이브리드 및 웹 애플리케이션에 대한 테스트 사례를 자동화하는 데 사용됩니다. Appium은 Android 및 iOS 모두에 중점을두고 있으며 모바일 애플리케이션 테스트 도메인으로 만 제한되었습니다. 또한 Appium은 최근에 몇 가지 업데이트를 통해 Windows 용 데스크톱 응용 프로그램 테스트를 지원한다고합니다.

Appium은 Sauce Labs에서 개발 및 유지 관리합니다. 현재 Appium 버전 1.12가 배포되고 있습니다. Appium은 처음으로 node.js를 사용하여 설치할 수있는 명령 줄 기반 테스트 서비스입니다 .

[Appium 특징]

Appium (클라이언트 - 서버) 아키텍처 : Appium의 핵심은 node.js로 작성된 서버입니다. 그래서 서버는 클라이언트- 서버 아키텍처를 사용해 작동합니다. 클라이언트-서버 아키텍처에 따르면 클라이언트는 서버에서 호스팅되는 모든 서비스를 사용하기 위해 서버에 연결합니다. 그래서 클라이언트와 서버 간의 모든 통신은 Response 및 Request의 형태입니다. Appium에서 클라이언트는 자동화 관련 요청을 Appium 서버로 보냅니다. 서버는 자체 고유 한 방식으로 Request을 처리하며, 잠시 후 이를 확인하고 다음 테스트 결과 또는 로그 파일로 Response를 보냅니다.
Appium Sessions : 모든 테스트는 Session에 캡슐화되어 수행됩니다. 이는 Appium이 간단한 클라이언트 및 서버 기반 메커니즘이기 때문입니다. 클라이언트는 Session Request를 서버에 보냅니다. 이러한 요청은 JSON Object 형식으로 보내집니다 그리고 이는 JSON Wire Protocol을 사용하여 서로 통신합니다.
Desired Capabilities : Appium은 iOS와 Android에서 다르게 작동합니다. 이제는 "크로스 플랫폼"도구이므로 두 운영 체제의 Session Request를 구분하는 메커니즘이 있어야합니다. 이 특정 문제 설명은 Desired Capablilities라고하는 JSON 객체를 사용하여 해결되었습니다. Desired Capabilities는 Android 앱 테스트를 위한 Session 설정과 iOS 앱 테스트를 구분하는 정보의 키-값 쌍입니다.
다음과 같은 인수 PlatformName ,Device Name, AppPackage, AppActivity로 두 운영체제를 구별합니다.

[JSON Wire Protocol]

JSON Wire Protocol은 클라이언트와 서버 간의 통신에 사용되는 메커니즘이며 WebDriver 개발자 가

개발 했습니다. 그들에 따르면 프로토콜은 RESTful API를 사용하여 클라이언트에 노출되는 표준화 된 그룹입니다. 이를 통해 웹 드라이버는 서버 및 클라이언트와의 통신을 설정하여 자동화를 수행 할 수 있습니다.
Appium은 Selenium JSON Wire Protocol의 확장 인 모바일 JSON Wire Protocol을 사용합니다. 통신 스트림을 설정하는 것 외에 다른 휴대폰 동작을 제어하는 데 사용됩니다.

[Appium Architecture]

Appium은 node.js를 사용하여 작성된 HTTP 서버 입니다.
클라이언트는 세션을 사용하여 서버와 통신합니다. 여기서 통신 프로세스의 핵심 요소는 도움말 JSON 개체 와 함께 전송 됩니다. 통신은 모바일 JSON 유선 프로토콜에 의해 처리됩니다.
서버는 desiredCapabilites 인수를 사용하여 iOS 요청과 Android 요청을 구분합니다 .
Appium 서버는 아래 Appium 아키텍처 다이어그램 에 표시된대로 각 UI Automators에 대한 요청을 처리합니다 .
UI Automator는 요청을 처리하고 시뮬레이터 / 에뮬레이터 / 실제 장치 에서 명령을 실행합니다 .
테스트 세션의 결과는 서버에 전달 된 다음 모바일 JSON 유선 프로토콜을 사용하여 로그 측면에서 클라이언트 시스템으로 다시 전달됩니다.

[UIAutoMator]

UI Automator 테스트 프레임워크는 사용자 앱과 시스템 앱에 관한 상호작용을 실행하는 UI 테스트를 빌드하기 위한 API 세트를 제공합니다. UI Automator API를 사용하면 테스트 기기에서 Settings 메뉴 또는 앱 런처 열기와 같은 작업을 실행할 수 있습니다. UI Automator 테스트 프레임워크는 블랙박스 스타일의 자동화된 테스트를 작성하기에 매우 적합하며, 여기서는 테스트 코드가 타겟 앱의 내부 구현 세부정보에 의존하지 않습니다.

참고문헌

developer.android.com/training/testing/ui-automator?hl=ko

UI Automator | Android 개발자 | Android Developers

UI Automator는 시스템과 설치된 앱 전반에 걸쳐 앱 간의 기능적 UI 테스트를 실행하기에 적합한 UI 테스트 프레임워크입니다. 참고: 이 프레임워크에는 Android 4.3(API 수준 18) 이상이 필요합니다. UI Aut

developer.android.com

[Appium Android 작동방식]

Appium 클라이언트 (c / Java / Python / etc)는 Appium Server와 연결하고 JSON Wire Protocol을 통해 통신합니다.
Appium Server는 클라이언트에 대한 자동화 세션을 생성하고 원하는 클라이언트 기능도 확인합니다. 그런 다음 UIAutomator와 같은 각 벤더 제공 프레임 워크와 연결됩니다.
UIAutomator는 클라이언트 작업을 수행하기 위해 시뮬레이터 / 에뮬레이터 / 실제 장치에서 실행중인 bootstrap.jar와 통신합니다.
여기서 bootstrap.jar 는 TCP 서버의 역할을하며, UIAutomator를 사용하여 Android 기기에서 작업을 수행하기 위해 테스트 명령을 보내는 데 사용할 수 있습니다.

Android(안드로이드) - Espresso

JY-Dev — Wed, 28 Oct 2020 17:23:29 +0900

[OverView]

Espresso에 대해 간략하게 정리하겠습니다.

[Espresso]

Espresso API는 테스트 작성자에게 사용자가 (UI요소들을 위치에 두고 그들과 상호 작용하는) 어플리케이션과 상호 작용하는 동안 무엇을 할 것인지의 관점으로 생각하는 것을 도와줍니다. 동시에 이 프레임워크는 어플리케이션의 Activity들과 View들에 직접 접근하는 것을 막습니다. 왜냐하면 이 객체들을 잡고 UI 스레드에서 시작된 이것들에 작업을 하는 것이 비정상적인 테스트의 주된 원인이기 때문입니다. 그러므로, Espresso API에서 getView나 getCurrentActivity같은 메소드들을 볼 수 없을 것입니다. 하지만 여전히 ViewAction들과 ViewAssertions들을 구현함을 통해 View에서 안전하게 작업을 할 수 있습니다.

[Espresso의 주요 구성 요소]

Espresso – View들과의 상호 작용을 할수있는(onView와 onData를 통해서). 또한 어떤 뷰와도 Binding 할 필요가 없는 APIs들을 노출합니다(pressBack).
ViewMatchers – Matcher<? super View> 인터페이스를 구현한 객체들의 모임. 현재 View 계층 내에 위치한 view의 위치를 찾기 위해 하나 또는 그 이상의 ViewMatchers를 onView 메소드에게 전달할 수 있습니다.
ViewActions – ViewInteraction.perform() 메소드에게 전달할 수 있는 ViewAction들의 모임 (예를 들어, click())
ViewAssertions – ViewInteraction.check() 메서드에 전달할 수 있는 ViewAssertion 객체의 컬렉션입니다. 대부분 뷰 매처를 사용하여 현재 선택된 뷰의 상태를 어설션하는 matches 어설션을 사용합니다.

Example: 간단한 버튼 클릭 테스트

@Rule
    @JvmField
    var mActivityTestRule = ActivityTestRule(MainActivity::class.java)

@Test
    fun useAppContext() {
        onView(withId(R.id.test_btn)).perform(click())
    }

[Onview() 와 Ondata()]

Onview() 는 기본적으로 UI 상에 보여지는 것에 대해 액세스 해서 View와 상호작용 할 수 있습니다.
Ondata() 는 예를들어 ListView에 여러 요소들이 있을 경우 화면에 보여지지 않은 데이터에 엑세스가 가능합니다.

ViewActions의 여러 메소드들은 아래링크에서 확인이 가능합니다.

https://developer.android.com/reference/android/support/test/espresso/action/ViewActions

ViewActions | Android 개발자 | Android Developers

ViewActions This package is part of the Android support library which is no longer maintained. The support library has been superseded by AndroidX which is part of Jetpack. We recommend using the AndroidX libraries in all new projects. You should also cons

developer.android.com

[디버깅]

Espresso는 테스트 실패시 유용한 디버깅 정보를 제공한다.

[로깅]

Espresso는 logcat에 모든 view 행위들을 로그를 남긴다.

[View hierarchy]

Espresso는 onView()가 실패했을 때 예외 문구안에 view 계층을 출력합니다. * 만약 onView()가 타겟 view를 찾지 못하면, NoMatchingViewException가 던져집니다. 왜 matcher가 어떤 view들과도 일치하지 않았는지 분석하기 위해 예외 스트링에서 view 계층을 조사할 수 있습니다. * 만약 onView()가 주어진 matcher와 일치하는 view을 여러개 찾으면, AmbiguousViewMatcherException이 발생합니다. View 계층이 출력되고 일치하는 모든 뷰들은 MATCHES 라벨로 마크될 것입니다.

java.lang.RuntimeException: com.google.android.apps.common.testing.ui.espresso.AmbiguousViewMatcherException: This matcher matches multiple views in the hierarchy: (withId: is <123456789>) … +----->SomeView{id=123456789, res-name=plus_one_standard_ann_button, visibility=VISIBLE, width=523, height=48, has-focus=false, has-focusable=true, window-focus=true, is-focused=false, is-focusable=false, enabled=true, selected=false, is-layout-requested=false, text=, root-is-layout-requested=false, x=0.0, y=625.0, child-count=1} ****MATCHES**** | +------>OtherView{id=123456789, res-name=plus_one_standard_ann_button, visibility=VISIBLE, width=523, height=48, has-focus=false, has-focusable=true, window-focus=true, is-focused=false, is-focusable=true, enabled=true, selected=false, is-layout-requested=false, text=Hello!, root-is-layout-requested=false, x=0.0, y=0.0, child-count=1} ****MATCHES**** When dealing with a complicated view hierarchy or unexpected behavior of widgets it is always helpful to use the Android View Hierarchy Viewer for an explanation.

[AdapterView warnings]

Espresso는 사용자에게 AdapterView 위젯들이 존재함을 경고합니다. 만약 onView() 작업이 NoMatchingViewException을 던지고 AdapterView 위젯들이 view 계층에 존재한다면, 가장 흔한 해결책은 onData()를 사용하는 것입니다. 예외 메시지는 adapter view들의 목록을 가진 경고를 포함할 것입니다. 당신은 타겟 view를 로드하기 위해 onData를 부르는데 이 정보를 이용할 것 입니다.

Android(안드로이드) - Junit Annotaion (어노테이션)

JY-Dev — Wed, 28 Oct 2020 17:15:05 +0900

[Junit Annotaion ]

@BeforeClass -이 매개 변수와 함께 Annotation이 지정된 메서드는 정적이어야 하며 먼저 실행되고 한번만 실행된다. -테스트 사례 클래스를 실행하기 전에 실행해야 하는 사전 조건을 설정하는 데 사용할 수 있다.
@Rule -단일 활동에 대한 기능 테스트 제공한다. -규칙을 사용하여 활동에 액세스 할 수 있으며 다음을 통해 리소스 등에 액세스 할 수 있다.
@Before -이 방법을 사용하면 다음에 대해 모든 테스트를 수행하기 전에 이 방법을 실행한다. -각 조건을 실행하기 전에 실행해야 하는 사전 조건을 설정하는 데 사용할 수 있다.
@Test -@Test로 표시된 방법은 @Before 다음에 실행된다.
@Ignores - 이 주석은 테스트 실행 중에 일부 테스트 케이스를 비활성화하기 위해 테스트 실행 중에 일부 명령문을 무시하려는 경우 사용할 수 있습니다.
@After - 이 Annotation과 함께 표시된 메서드는 메서드에 대한 모든 테스트가 두번 실행된 후에 실행됩니다. - 테스트 방법 후 변수를 재설정하는 데 사용할 수 있다.
@AfterClass - Annotation이 붙은 방법은 정적이어야 하며 마지막으로 한번만 실행된다. - Annotation을 사용하여 Junit테스트 사례 클래스의 모든 테스트를 실행한 후 실행해야 하는 방법을 실행할 수 있다.

[프래그먼트 사용시]

테스트를 실행하기 전에 작업을 먼저 수행해야한다는 것을 JUnit에게 알려주기 만하면된다. "init()"함수라 부르며, @Before 어노테이션으로 주석을 붙임으로써 완성된다.

@Before
public void init(){
    activityActivityTestRule.getActivity()
            .getSupportFragmentManager().beginTransaction();
}

ANDROID TDD

JY-Dev — Tue, 27 Oct 2020 14:25:44 +0900

[실행 환경을 기반으로 테스트 디렉터리 구성]

Android 스튜디오의 일반 프로젝트에는 테스트를 배치하는 두 개의 디렉터리가 포함되어 있습니다. 다음과 같이 테스트를 구성하세요.

androidTest 디렉터리에는 실제 또는 가상 기기에서 실행되는 테스트가 포함되어야 합니다. 이러한 테스트에는 통합 테스트, 엔드 투 엔드 테스트 및 JVM만으로 앱 기능의 유효성을 검사할 수 없는 기타 테스트가 포함됩니다.
test 디렉터리에는 로컬 시스템에서 실행되는 테스트(예: 단위 테스트)가 포함되어야 합니다.

[여러 유형의 기기에서 테스트를 실행하는 경우의 장단점 고려]

기기에서 테스트를 실행하는 경우 다음 유형 중에서 선택할 수 있습니다.

실제 기기
가상 기기(예: Android 스튜디오의 에뮬레이터)
시뮬레이션된 기기(예: Robolectric)

실제 기기는 가장 높은 충실도를 제공하지만 테스트를 실행하는 데 가장 많은 시간이 소요됩니다. 반면에 시뮬레이션된 기기는 낮은 충실도 대신 향상된 테스트 속도를 제공합니다. 그러나 플랫폼의 바이너리 리소스 및 사실적 루퍼 개선으로 시뮬레이션된 기기가 보다 사실적인 결과를 생성할 수 있습니다.

가상 기기는 충실도와 속도 간 균형을 제공합니다. 가상 기기를 사용하여 테스트하는 경우 테스트 간 설정 시간을 최소화하려면 스냅샷을 사용하세요.

[테스트 더블 사용 여부 고려]

출처 : http://xunitpatterns.com/Test%20Double.html

테스트 더블

메스자로스(Gerard Mezaros)가 "xUnitText Patterns"에서 만들어낸 용어로 테스트를 진행하기 어려운 경우 이를 대신해 테스트를 진행 할 수 있도록 만들어주는 객체를 말한다. * Mock 객체와 유사한 의미를 가지며 테스트 더블이 좀더 상위 의미로 사용된다.

더미객체(Dummy Object)

단순히 인스턴스화될 수 있는 수준으로만 객체를 구현한다.
인스턴스화된 객체가 필요할 뿐 해당 객체의 기능까지는 필요하지 않은 경우에 사용한다.

테스트 스텁(Test Stub)

더미 객체 보다 좀더 구현된 객체로 더미 객체가 마치 실제로 동작하는 것처럼 보이게 단들어 놓은 객체이다.
객체의 특정 상태를 가정해서 만들어 특정 값을 리턴해 주거나 특정 메시지를 출력해 주는 작업을 한다.
특정 상태를 가정해서 하드코딩된 형태이기 때문에 로직에 따른 값의 변경은 테스트 할 수 없다.

페이크 객체(Fake Object)

여러 상태를 대표할 수 있도록 구현된 객체로 실제 로직이 구현된 것처럼 보이게 한다.
실제로 DB에 접속해서 비교할 때와 동일한 모양이 보이도록 객체 내부에 구현 할 수 있다.
- 테스트케이스 작성을 위해서 다른 객체들과의 의존성을 제거하기 위해 사용한다.
- 페이크 객체를 만들 때 복잡도로 인해서 노력이 많이 들어 갈 경우 적절한 수준에서 구현하거나, Mock 프레임 워크를 사용한다.
- 페이크 객체를 생성하기 위한 노력이 많이 필요한 경우 실제 객체를 가져와 테스트 한다.

테스트 스파이(Test Spy)

테스트에 사용되는 객체, 메소드의 사용 여부 및 정상 호출 여부를 기록하고 요청시 알려준다.
테스트 더블로 구현된 객체에 자기 자신이 호출 되었을 때 확인이 필요한 부분을 기록하도록 구현한다.
특정 테스트 메서드가 몇번 호출 되었는지 필요한 경우 전역 변수로 카운트를 설정하고 특정 테스트 메서드에 카운트를 올리는 부분을 추가한 후 이 카운트를 가져오는 메서드를 추가한다.
아주 특수한 경우를 제외하고는 잘 쓰이지 않으며 보통 Mock 프레임워크에서 기본적으로 기능을 제공하므로 Mock을 사용한다.
특정 메소드가 호출 되었을 때 또 다른 메서드가 실행이 되어야 한다와 같은 행위 기반 테스트가 필요한 경우 사용한다.

Mock 객체(Mock Object)

행위를 검증하기 위해 사용되는 객체를 지칭하며 수동으로 만들 수도 있고 프레임워크를 통해 만들 수 있다.
행위 기반 테스트는 복잡도나 정확성등 작성하기 어려운 부분이 많기 때문에 상태 기반 테스트가 가능하다면 만들지 않는다.
Mock 객체는 테스트 더블 하위객체로 써의 좁은 의미와 테스트 더블을 포함한 넓은 의미 2가지로 사용 될 수 있다.

[Android Test]

안드로이드 테스트는 크게 다음의 2가지가 있습니다.

Unit Test
Instrumentation Test

Unit Test 는 말 그대로 "단위 테스트"(함수 테스트)를 의미합니다. 흔히 TDD로 개발하게 되면, 매 "기능 단위별"로 테스트 코드를 구성하게 되고, 그 테스트 코드를 통과하는 실제 코드를 작성하곤 하지요. 혹은 그 반대도 가능하구요. 이때 사용되는 테스트 코드가 Unit Test 입니다.
해당 테스트를 수행하기 위해서는 module-name/src/test/java/ 하위에 테스트 코드를 작성하면 됩니다.

Android 컴포넌트들을 그대로 Unit Test 코드상에서 사용하면, 테스트는 실패합니다. Unit Test에서 사용하는 Android 컴포넌트들은 android-stubs-src.jar 파일을 참조하기 때문인데요, 해당 파일은 빈 껍데기(Stub)들만 모여있기에, 실행될 수 없습니다.
즉, 아래에서 설명하는 Instrumentation Test가 필요한 계기가 됩니다.

Instrumentation Test 는 실제 하드웨어 기기나 에뮬레이터에서 실행되는 테스트입니다. 안드로이드 환경에서 테스트하기 때문에 실제 Instrumentation Api 에 접근 가능합니다. Android 환경에서 실행되는 AndroidJUnitRunner를 통해서 실행됩니다.

해당 테스트는 module-name/src/androidTest/java/ 하위에 테스트 코드를 작성합니다. Instrumentation Test 는 Unit Test에 비해서, 그 속도가 느린 것이 단점입니다. 실제로 앱을 빌드 하고, 배포 하며, 실행 시키는 과정이 매 테스트마다 포함되기에 그렇습니다.

그래서 Unit Test에서 Instrumentation Api을 후킹할수 있도록 만들어진 것이 Mock Library입니다.

Mock 객체

JY-Dev — Tue, 27 Oct 2020 14:14:41 +0900

[Mock 객체란]

Mock Object는 검사하고자 하는 코드와 맞물려 동작하는 객체들을 대신하여 임의적으로 동작하기 위해 만들어진 객체입니다. 검사하고자 하는 코드는 Mock Object의 메서드를 부를 수 있고 이 때 Mock Object는 미리 정의된 결과 값을 전달합니다. Mock Object는 자신에게 전달된 인자를 검사할 수 있으며, 이를 테스트 코드로 전달할 수도 있습니다. 그래서 이 가짜 객체를 이용하면 상당 부분의 테스트를 사용자의 개입 없이 자동화 할 수 있습니다.

[사전적 의미]

Mock : 무시하다, 거짓된, 가짜의 의미
조각하기 쉬운 재료를 이용해 추후 만들어질 제품의 외양을 흉내 낸 모조품

[Mock 객체가 필요한 경우]

테스트 작성을 위한 환경 구축이 어려울 경우
환경 구축을 위한 작업 시간이 많이 필요한 경우
특정 모듈을 갖고 있지 않아서 테스트 환경 구축이 어려운경우
테스트 시간이 오래 걸리는 경우
테스트가 특정 경우나 순간에 의존적인 경우

[Mock 프레임워크]

동적으로 mock 객체를 만들어 주는 프레임워크이며 사용시 아래의 장점이 있다.
Mock 객체를 명시적으로 생성하지 않아도 된다.
행위기반 테스트도 가능하다.

1. EasyMock

가장 오래된 Mock프레임워크이며, 오픈소스로 탐 프리스가 만들었다.
홈페이지는 http://easymock.org 이다.
일반적으로 Mock 프레임워크는 인터페이스를 통해 객체를 생성하는데 EasyMock Class Extention이라는 기능을 통해 구현 클래스를 통하여 객체를 생성하도록 지원한다.
기본적으로 4단계를 통하여 동작하며 각 단계는 생략될 수 있다.
- CreateMock : 인터페이스에 해당하는 Mock 객체를 생성한다.
- Record : Mock 객체 메소드의 예상되는 동작을 녹화한다.
- Replay : 예정된 상태로 재생한다.
  - Verify : 예정된 행위가 발생했는지 검증한다.
  - 녹화, 재생이라는 개념은 처음 접하는 사람들에게는 어려운 개념이다. 그러나, 가장 오래된 프레임워크라서 과거에 많이 사용되었기 때문에 읽을 수 있을 정도는 배워두는 것이 좋다.

2. jMock

스티프 프리만, 냇 프라이스가 만든 프레임 워크로 테스트 표현의 확대와 가독성이 좋다.
- 홈페이지는 http://www.jmock.org 이다.
- 특징은 아래와 같다.
  - 연쇄호출(call-chain) : 동일한 객체에 여러 개의 메세지를 보낼 수 있다. void로 선언된 메서드도 플로우를 만들어서 순차 호출 할 수 있다.
전용 Macher 사용 : 기본적으로 Hamcrest Macher 라이브러리를 사용한다.
기본적으로 아래의 4단계로 진행된다.
- CreateMock : 인터페이스에 해당하는 Mock 객체를 생성한다.
- Expect : Mock 객체의 예상되는 동작을 미리 지정한다.
- Excercise : 테스트 메소드 내에서 Mock 객체를 사용한다.
- Verify : 예상한 행위가 발생했는지 검증한다. 사용자가 작성하지 않고 프레임워크가 자동으로 판단한다.

3. Mockito

역사는 오래되지 않았지만 간편한 사용법으로 빠르게 확산되고 있으며 상태 기반 테스트를 지원한다.
- 홈페이지는 https://code.google.com/p/mockito/ 이다.
- 특징은 아래와 같다.
  - 사용법이 단순하다.
  - call("getName")처럼 이름이 호출하지 않는다.
  - 읽기 어려운 anonymous inner클래스를 사용하지 않는다.
  - 리펙토링이 쉽다.
  - 작성이 어렵지 않아 테스트 자체에 집중할 수 있다.
  - 테스트 스텁을 만드는 것과 검증을 분리한다.
  - Mock 만드는 방법을 단일화 했다.
  - 테스트 스텁을 만들기 쉽다.
  - API가 간단하다.
  - 실패 시에 발생하는 스택 트레이스가 깔끔하다.
- 아래의 4단계로 진행된다.
  - CreateMock : 인터페이스에 해당되는 Mock 객체를 만든다.
  - Stub : 테스트에 필요한 Mock 객체의 동작을 지정한다.
  - Excercise : 테스트 메소드 내에서 Mock 객체를 사용한다.
  - Verify : 메서드가 예상되로 호출되었는지 검증한다.

[Mock 사용시 유의사항]

Mock 프레임워크가 정말 필요한지 확인한다.
Mock을 사용하는 경우 테스트 케이스 유지에 복잡성이 더해지기 때문에 Mock이 없는 의존성 적은 구조로 프로그래밍 한다.
어떤 Mock 프레임워크를 사용하느냐는 핵심 문제가 아니다.
- 어떤 프레임워크를 사용하느냐에 따라 테스트 케이스 작성에 커다란 영향이 미치지 않는다. 단지 익숙해지기 까지 시간이 필요할 뿐이다.
Mock 객체는 Mock 일 뿐이다.
실제 객체로 작동을 해보았을 때 잘 작동하지 않을 수도 있다. Mock 객체는 흉내를 내는 객체이기 때문이다.

Kotlin Scratch(스크래치) 사용하기

JY-Dev — Mon, 26 Oct 2020 15:07:41 +0900

[OverView]

안드로이드 스튜디오에서는 스크래치라는 기능을 제공합니다.

이 기능을 통해 Kotlin을 학습하고 쉽게 컴파일 할 수 있습니다.

스크래치 기능을 사용하려면 오른쪽 프로젝트 탭에서 마우스 오른쪽 클릭후 New에서 Scratch File을 선택해주면 여러가지가 나오는데 여기서 Kotlin을 눌러주시면

이런식으로 컴파일 할 수가 있습니다.

Kotlin이란 ?

JY-Dev — Mon, 26 Oct 2020 15:02:32 +0900

[OverView]

- 요즘 안드로이드 개발 방향이 Java에서 Kotlin으로 넘어가는 추세입니다.

그 이유는 2017 구글 I/O에서 정식으로 안드로이드 개발언어로 Kotlin을 채택되었기 때문입니다.

- 코틀린은 JVM 위에서 동작하며 100%로 호환됩니다. 자바의 수많은 라이브러리를 그대로 사용하면서 코든느 더 간결하게 작성할 수 있습니다. 즉 같은 기능을 구현하더라도 자바에 비해서 더 코드를 적게 작성하게되서 생산적인 부분에서 많은 이점이 있습니다.

- 2018 구글 I/O에서는 대부분의 예제를 코틀린으로 설명하고 있습니다.

[특징]

- 간결한 코드 : 상용구 코드양을 대폭 줄여줍니다. 예를 들어 자바에서는 단순한 클래스를 작성할때 게터 및 세터를 잔뜩 만들고 equals(), hashcode(), toString()을 재정의해서 수십줄의 코드를 작성하게 됩니다. 코틀린은 게터 및 세터가 필요없고 data class 에서 한줄로 해결이 가능합니다.

- 안정성 : null 포인터 같은 예외 오류를 피할 수 있습니다.

- 상호 운용성 : 기존 자바 라이브러리와 100% 호환 됩니다.

- 도구 친화적 : 자바, 안드로이드 개발도구에서 그대로 사용 가능합니다.

[사용의 이점]

안드로이드 자바는 자바6의 늪에 빠져있다고 봐도 과언이 아닙니다. 현재 안드로이드 개발에서 자바 8의 일부 기능을 사용할 수 있습니다. 하지만 대상 API를 24 이상(Android 7.0) 으로 설정했을 때만 사용가능한 기능이 많습니다. 현재 안드로이드 7.0 이상의 기기 보급률은 매우 낮기 때문에 현실적으로는 자바 최신 기술을 사용할 수 없습니다.

코틀린을 사용하면 안드로이드 버전에 관계없이 현대 언어의 장점을 사용할 수 있습니다.

안드로이드 개발에서 코틀린을 사용한 이점은 아래와 같습니다.

- 호환성 : 코틀린은 JDK 6과 완벽하게 호환되므로 구형 안드로이드 기기에서도 완벽하게 실행됩니다. 그리고 코틀린 개발 도구는 안드로이드 스튜디오에서 완벽히 지원되므로 안드로이드 빌드 시스템과도 완벽히 호환됩니다.

- 성능 : 코틀린은 자바 만큼 빠르거나 종종 람다로 실행되는 코드는 종종 자바보다 훨씬 빠르게 동작합니다.

- 상호 운용성 : 코틀린은 자바와 100% 상호 운용이 가능하며 기존의 모든 안드로이드 라이브러리를 사용 할 수 있습니다.

- 학습 곡선 : 자바 개발자가 코틀린을 배우기 매우 쉽습니다. 안드로이드 스튜디오는 자바 코드를 코틀린으로 자동으로 변환해 주는 도구를 제공합니다.