레이블이 uiautomator인 게시물을 표시합니다. 모든 게시물 표시
레이블이 uiautomator인 게시물을 표시합니다. 모든 게시물 표시

2017년 8월 18일 금요일

Testing UI for Multiple Apps

Testing UI for Multiple Apps


Dependencies and Prerequisites

This lesson teaches you to

  1. Set Up UI Automator
  2. Create a UI Automator Test Class
  3. Run UI Automator Tests on a Device or Emulator

You should also read

Try it out

다중앱을 커버하는 사용자 상호작용과 연관된 UI 테스트는 사용자 흐름이 다른 앱들과 시스템 UI와 얽혀있을때 앱이 정확하게 동작하는지 확인해준다. 그러한 흐름의 예는 텍스트를 입력하는 메시징 앱이 안드로이드 contact picker를 띄워서 사용자가 메시지를 보낼 수신자를 선택할 수 있게 하고 나서 사용자가 메시지 보내기 위해 원래 앱으로 제어를 리턴하도록 하는 것이다.
이 문서는  Android Testing Support Library 가 제공하는  UI automator test framework를 사용하여 어떻게 UI 테스트를 작성하는가를 다룬다. UI Automator API는 어떤 액티비티가 포커스를 가지고 있는지 상관없이 장치의 보이는 요소들과 상호작용할 수 있도록 해준다. 당신의 테스트는 컴포넌트에 보여지는 텍스트나 그것의 컨텐츠 디스크립터와 같은 편리한 디스크립터를 사용하여 UI 컴포넌트를 찾을 수 있다. UI Automator 테스트는 안드로이드 4.3(API level 18) 이상에서 동작하는 장치에서 실행할 수 있다. UI Automator 테스팅 프레임워크는 장치 기반의 API이고 Android Testing Support Library test runner와 함께 동작한다.

Set Up UI Automator


UI automator를 사용하여 당신의 UI test를 작성하기 전에 Getting Started with Testing 에 나와 있는데로 당신의 테스트 코드 위치와 프로젝트 디펜던시를 설정해야 한다.
당신의 안드로이드 앱 모듈에 있는 build.gradle 파일에 UI Automator library에 대한 의존성 참조를 셋팅해야 한다:

dependencies {
    ...
    androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.1'
}
 
 
UI Automator 테스팅을 최적화 하기 위해서는 먼저 타겟 앱의 UI 컴포넌트들을 조사하고 그것들에 접근 가능한지 확인해야 한다. 이들 최적화 팁은 다음 두 섹션에서 설명한다.

Inspecting the UI on a device

테스트를 디자인하기 전에, 장치에 보이는 UI 컴포넌트들을 조사한다. 당신의 UI Automator 테스트가 이들 컴포넌트에 접근할 수 있는지 확인하기 위해 이들 컴포넌트들이 보이는 텍스트 라벨과 android:contentDescription 혹은 둘다를 가지고 있는지 체크한다.
장치의 foreground 상에 보이는 UI 컴포넌트들의 특성을 보고 레이아웃 계층을 조사하기 위한 편리한 비주얼 인터페이스를 제공하는 uiautomatorviewer 툴을 제공한다. 이 정보들은 UI Automator를 사용하여 더 매끄러운 테스트를 작성할 수 있도록 해준다. 예를 들어 당신은 특정한 보이는 속성과 매치하는 UI selector를 작성할 수 있다.

uiautomatorviewer 툴을 띄우기 위해:
To launch the uiautomatorviewer tool:
  1. 물리 장치에 타겟 앱을 띄운다.
  2. 개발 머신에 물리장치를 연결한다.
  3. 터미널 윈도우를 열어서 <android-sdk>/tools/ 디렉토리로 이동한다.
  4. 다음 명령을 이용하여 툴을 실행한다.:
    $ uiautomatorviewe
애플리케이션을 위한 UI 속성들을 보기 위해:
  1. uiautomatorviewer 인터페이스 상에서 , Device Screenshot 버튼을 클릭한다..
  2. uiautomatorviewer 툴에 의해 인식된 UI 컴포넌트들을 보여주는 왼족 패널 상의 snapshot 상에 마우스 커서를 가져다댄다. 속성들이 오른쪽 패널 하단에 리스팅되고 오른쪽 패널 상단에는 레이아웃 계층이 표시된다.
  3. 선택적으로 UI Automator에서 접근할 수 없는 UI 컴포넌트들을 보기 위해서는 Toggle NAF Nodes 버튼을 클릭한다. 이들 컴포넌트를 위해서는 제한된 정보만 사용할 수 있다.
안드로이드에 의해 제공되는 UI 컴포넌트들의 일반적인 타입들에 대해 알고 싶다면 User Interface.를 보아라.

Ensuring your Activity is accessible

The UI Automator test framework performs better on apps that have implemented Android accessibility features. When you use UI elements of type View, or a subclass of View from the SDK or Support Library, you don't need to implement accessibility support, as these classes have already done that for you.
Some apps, however, use custom UI elements to provide a richer user experience. Such elements won't provide automatic accessibility support. If your app contains instances of a subclass of View that isn't from the SDK or Support Library, make sure that you add accessibility features to these elements by completing the following steps:
  1. Create a concrete class that extends ExploreByTouchHelper.
  2. Associate an instance of your new class with a specific custom UI element by calling setAccessibilityDelegate().
For additional guidance on adding accessibility features to custom view elements, see Building Accessible Custom Views. To learn more about general best practices for accessibility on Android, see Making Apps More Accessible.

Create a UI Automator Test Class


Your UI Automator test class should be written the same way as a JUnit 4 test class. To learn more about creating JUnit 4 test classes and using JUnit 4 assertions and annotations, see Create an Instrumented Unit Test Class.
Add the @RunWith(AndroidJUnit4.class) annotation at the beginning of your test class definition. You also need to specify the AndroidJUnitRunner class provided in the Android Testing Support Library as your default test runner. This step is described in more detail in Run UI Automator Tests on a Device or Emulator.
Implement the following programming model in your UI Automator test class:
  1. Get a UiDevice object to access the device you want to test, by calling the getInstance() method and passing it an Instrumentation object as the argument.
  2. Get a UiObject object to access a UI component that is displayed on the device (for example, the current view in the foreground), by calling the findObject() method.
  3. Simulate a specific user interaction to perform on that UI component, by calling a UiObject method; for example, call performMultiPointerGesture() to simulate a multi-touch gesture, and setText() to edit a text field. You can call on the APIs in steps 2 and 3 repeatedly as necessary to test more complex user interactions that involve multiple UI components or sequences of user actions.
  4. Check that the UI reflects the expected state or behavior, after these user interactions are performed.
These steps are covered in more detail in the sections below.

Accessing UI Components

The UiDevice object is the primary way you access and manipulate the state of the device. In your tests, you can call UiDevice methods to check for the state of various properties, such as current orientation or display size. Your test can use the UiDevice object to perform device-level actions, such as forcing the device into a specific rotation, pressing D-pad hardware buttons, and pressing the Home and Menu buttons.
It’s good practice to start your test from the Home screen of the device. From the Home screen (or some other starting location you’ve chosen in the device), you can call the methods provided by the UI Automator API to select and interact with specific UI elements.
The following code snippet shows how your test might get an instance of UiDevice and simulate a Home button press:
import org.junit.Before;
import android.support.test.runner.AndroidJUnit4;
import android.support.test.uiautomator.UiDevice;
import android.support.test.uiautomator.By;
import android.support.test.uiautomator.Until;
...
@RunWith(AndroidJUnit4.class)
@SdkSuppress(minSdkVersion = 18)
public class ChangeTextBehaviorTest {

    private static final String BASIC_SAMPLE_PACKAGE
            = "com.example.android.testing.uiautomator.BasicSample";
    private static final int LAUNCH_TIMEOUT = 5000;
    private static final String STRING_TO_BE_TYPED = "UiAutomator";
    private UiDevice mDevice;

    @Before
    public void startMainActivityFromHomeScreen() {
        // Initialize UiDevice instance
        mDevice = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());

        // Start from the home screen
        mDevice.pressHome();

        // Wait for launcher
        final String launcherPackage = mDevice.getLauncherPackageName();
        assertThat(launcherPackage, notNullValue());
        mDevice.wait(Until.hasObject(By.pkg(launcherPackage).depth(0)),
                LAUNCH_TIMEOUT);

        // Launch the app
        Context context = InstrumentationRegistry.getContext();
        final Intent intent = context.getPackageManager()
                .getLaunchIntentForPackage(BASIC_SAMPLE_PACKAGE);
        // Clear out any previous instances
        intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK);
        context.startActivity(intent);

        // Wait for the app to appear
        mDevice.wait(Until.hasObject(By.pkg(BASIC_SAMPLE_PACKAGE).depth(0)),
                LAUNCH_TIMEOUT);
    }
}
In the example, the @SdkSuppress(minSdkVersion = 18) statement helps to ensure that tests will only run on devices with Android 4.3 (API level 18) or higher, as required by the UI Automator framework.
Use the findObject() method to retrieve a UiObject which represents a view that matches a given selector criteria. You can reuse the UiObject instances that you have created in other parts of your app testing, as needed. Note that the UI Automator test framework searches the current display for a match every time your test uses a UiObject instance to click on a UI element or query a property.
The following snippet shows how your test might construct UiObject instances that represent a Cancel button and a OK button in an app.
UiObject cancelButton = mDevice.findObject(new UiSelector()
        .text("Cancel"))
        .className("android.widget.Button"));
UiObject okButton = mDevice.findObject(new UiSelector()
        .text("OK"))
        .className("android.widget.Button"));
// Simulate a user-click on the OK button, if found.
if(okButton.exists() && okButton.isEnabled()) {
    okButton.click();
}

Specifying a selector

If you want to access a specific UI component in an app, use the UiSelector class. This class represents a query for specific elements in the currently displayed UI.
If more than one matching element is found, the first matching element in the layout hierarchy is returned as the target UiObject. When constructing a UiSelector, you can chain together multiple properties to refine your search. If no matching UI element is found, a UiAutomatorObjectNotFoundException is thrown.
You can use the childSelector() method to nest multiple UiSelector instances. For example, the following code example shows how your test might specify a search to find the first ListView in the currently displayed UI, then search within that ListView to find a UI element with the text property Apps.
UiObject appItem = new UiObject(new UiSelector()
        .className("android.widget.ListView")
        .instance(0)
        .childSelector(new UiSelector()
        .text("Apps")));
As a best practice, when specifying a selector, you should use a Resource ID (if one is assigned to a UI element) instead of a text element or content-descriptor. Not all elements have a text element (for example, icons in a toolbar). Text selectors are brittle and can lead to test failures if there are minor changes to the UI. They may also not scale across different languages; your text selectors may not match translated strings.
It can be useful to specify the object state in your selector criteria. For example, if you want to select a list of all checked elements so that you can uncheck them, call the checked() method with the argument set to true.

Performing Actions

Once your test has obtained a UiObject object, you can call the methods in the UiObject class to perform user interactions on the UI component represented by that object. You can specify such actions as:
The UI Automator testing framework allows you to send an Intent or launch an Activity without using shell commands, by getting a Context object through getContext().
The following snippet shows how your test can use an Intent to launch the app under test. This approach is useful when you are only interested in testing the calculator app, and don't care about the launcher.
public void setUp() {
    ...

    // Launch a simple calculator app
    Context context = getInstrumentation().getContext();
    Intent intent = context.getPackageManager()
            .getLaunchIntentForPackage(CALC_PACKAGE);
    intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK);
            // Clear out any previous instances
    context.startActivity(intent);
    mDevice.wait(Until.hasObject(By.pkg(CALC_PACKAGE).depth(0)), TIMEOUT);
}

Performing actions on collections

Use the UiCollection class if you want to simulate user interactions on a collection of items (for example, songs in a music album or a list of emails in an Inbox). To create a UiCollection object, specify a UiSelector that searches for a UI container or a wrapper of other child UI elements, such as a layout view that contains child UI elements.
The following code snippet shows how your test might construct a UiCollection to represent a video album that is displayed within a FrameLayout:
UiCollection videos = new UiCollection(new UiSelector()
        .className("android.widget.FrameLayout"));
// Retrieve the number of videos in this collection:
int count = videos.getChildCount(new UiSelector()
        .className("android.widget.LinearLayout"));
// Find a specific video and simulate a user-click on it
UiObject video = videos.getChildByText(new UiSelector()
        .className("android.widget.LinearLayout"), "Cute Baby Laughing");
video.click();
// Simulate selecting a checkbox that is associated with the video
UiObject checkBox = video.getChild(new UiSelector()
        .className("android.widget.Checkbox"));
if(!checkBox.isSelected()) checkbox.click();

Performing actions on scrollable views

Use the UiScrollable class to simulate vertical or horizontal scrolling across a display. This technique is helpful when a UI element is positioned off-screen and you need to scroll to bring it into view.
The following code snippet shows how to simulate scrolling down the Settings menu and clicking on an About tablet option:
UiScrollable settingsItem = new UiScrollable(new UiSelector()
        .className("android.widget.ListView"));
UiObject about = settingsItem.getChildByText(new UiSelector()
        .className("android.widget.LinearLayout"), "About tablet");
about.click();

Verifying Results

The InstrumentationTestCase extends TestCase, so you can use standard JUnit Assert methods to test that UI components in the app return the expected results.
The following snippet shows how your test can locate several buttons in a calculator app, click on them in order, then verify that the correct result is displayed.
private static final String CALC_PACKAGE = "com.myexample.calc";
public void testTwoPlusThreeEqualsFive() {
    // Enter an equation: 2 + 3 = ?
    mDevice.findObject(new UiSelector()
            .packageName(CALC_PACKAGE).resourceId("two")).click();
    mDevice.findObject(new UiSelector()
            .packageName(CALC_PACKAGE).resourceId("plus")).click();
    mDevice.findObject(new UiSelector()
            .packageName(CALC_PACKAGE).resourceId("three")).click();
    mDevice.findObject(new UiSelector()
            .packageName(CALC_PACKAGE).resourceId("equals")).click();

    // Verify the result = 5
    UiObject result = mDevice.findObject(By.res(CALC_PACKAGE, "result"));
    assertEquals("5", result.getText());
}

Run UI Automator Tests on a Device or Emulator


You can run UI Automator tests from Android Studio or from the command-line. Make sure to specify AndroidJUnitRunner as the default instrumentation runner in your project.
To run your UI Automator test, follow the steps for running instrumented tests described in Getting Started with Testing.

2016년 6월 22일 수요일

Getting Started with Testing

Getting Started with Testing


test를 작성하고 실행하는 것은 안드로이드 앱 개발 사이틀에서 중요한 부분이다. 잘 작성한 테스트는 개발중에 일찍 버그를 잡을 수 있게 도와줄 수 있고 당신 코드에 자신감을 준다. 안드로이드 스튜디오를사용해서 다양한 물리 또는 가상 안드로이드 장치 상에서 local unit test나 instrumented test를 수행할 수 있다. 그러면 결과를 분석해서 개발환경을 벗어날 필요없이 당신의 코드에 수정작업을 할 수 있다.
Local unit tests 는 로컬 머신에서 실행하는 테스트이다. 이는 안드로이드 프레임워크나 안드로이드 장치에 접근할필요가 없다. local units tests를 작성하는지 배우려면 Building Local Unit Tests 를 보아라.
Instrumented tests 는 안드로이드 장치나 에뮬레이터상에서 실행하는 테스트이다. 테스트는 테스트 중에 앱의 Context 와 같은 Instrumentation information 에 접근한다. Instrumented tests는 unit, user interface(UI), 또는 app component integration testing에 사용될 수 있다. 구체적인 필요에 따라 어떻게 instrumented test를 개발하는지 알고 싶으면 다음의 추가적인 주제를 참조해라. :
이 레슨은 어떻게 안드로이드 스튜디오를 이용해서 테스트를 구축하고 실행시키는지 알려준다. 만약 안드로이드 스튜디오를 사용하고 있지 않는다면 run your tests from the command-line 를 사용할 수 있다.

Configure Your Project for Local Unit Tests


안드로이드 스튜디오 프로젝트에서 명확한 소스 디렉토리(src/test/java) 안에 local unit test를 위한 소스 파일들을 저장해야 한다. 이는 당신의 unit tests를 하나의 소스 집합으로 그룹핑함으로써 프로젝트 조직을 새선한다.
생산 코드와 함께 specific flavor or build type 을 위한 local unit tests를 생성할 수 있다. 당신의 unit test를 당신의 생산 소스 트리에 대응하는 test source tree 위치에 유지해라. 다음과 같이:
Path to Production ClassPath to Local Unit Test Class
src/main/java/Foo.javasrc/test/java/FooTest.java
src/debug/java/Foo.javasrc/testDebug/java/FooTest.java
src/myFlavor/java/Foo.javasrc/testMyFlavor/java/FooTest.java
JUnit 4 framework가 제공하는 표준 API들을 사용하는 당신의 프로젝트를 위해 테스팅 의존서을 설정할 필요가 있다. 테스트가 안드로이드 의존성과 상호작용할 필요가 있다면 Mockito 를 포함하여 당신의 local unit test를 단순화시켜라ㅏ. local unit tests에서 mock object를 사용하는 법은 Mocking Android dependencies 를 보아라.
당신 앱의 top-level build.gradle In에 의존성에 대해 이들 라이브러리를 명세할 필요가 있다. :
dependencies {
    // Required -- JUnit 4 framework
    testCompile 'junit:junit:4.12'
    // Optional -- Mockito framework
    testCompile 'org.mockito:mockito-core:1.10.19'
}

Configure Your Project for Instrumented Tests

안드로이드 스튜디오 프로젝트에서 특정 디렉토리(src/androidTest/java)에 당신의 instrumented tests를 위한 소스코드를 위치시켜야 한다.
 Android Testing Support Library Setup 를 다운르도 해라. 이는 당신의 앱을 위한 instrumented 테스트코드를 빠르게 구축하고 실행할 수 있도록 도와준다. Testing Support Library 는 JUnit4 test runner(AndroidJUnitRunner ) 와 기능적인 UI test(Espresso and UI Automator)를 위한 API들을 지원한다.
당신의 프로젝트가 Testing Support Library가 제공하는 test runner와 API 룰들을 사용할 수 있도록 Android testing dependencies 설정할 필요가 있다. 당신의 테스트 개발을 간단하게 하기 위해,우리는  Hamcrest라이브러리를 포함할 것을 추천한다. 이는 Harcrest matcher API들을 이용하여 좀더 유연한 assertions들을 생성할 수 있게 해준다.
당신앱의 top-level build.gradle 파일에, 의존성에 대한 이들 파일들을 명세할 필요가 있다.
dependencies {
    androidTestCompile 'com.android.support:support-annotations:23.0.1'
    androidTestCompile 'com.android.support.test:runner:0.4.1'
    androidTestCompile 'com.android.support.test:rules:0.4.1'
    // Optional -- Hamcrest library
    androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
    // Optional -- UI testing with Espresso
    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.1'
    // Optional -- UI testing with UI Automator
    androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.1'
}
To use JUnit 4 test classes, make sure to specify AndroidJUnitRunner as the default test instrumentation runner in your project by including the following setting in your app's module-level build.gradle file:
android {
    defaultConfig {
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
}

Work With Test Artifacts

Android Studio has two types of test artifacts: Android Instrumentation Tests and Unit Tests. Previously, you could work with just one test artifact at a time. Now, both test artifacts are enabled. The advantage of enabling both test artifacts is that any changes you make to the underlying code affect them both. For example, if you rename a class that both test artifacts access, both will know about the class name refactoring.
The figure shows what your project looks like with both test artifacts enabled. Notice the shading of both test artifacts.

Build and Run Your Tests


Android Studio provides all the tools you need to build, run, and analyze your tests within the development environment. You can also run instrumented tests on multiple device configurations, simultaneously, using Cloud Test Lab integration.
Note: While running or debugging instrumented tests, Android Studio does not inject the additional methods required for Instant Run and turns the feature off.

Run Local Unit Tests

To run your local unit tests:
  1. In the Project window, right click on the project and synchronize your project.
  2. In the Project window, navigate to your unit test class or method, then right-click it and select Run .
    • To run all tests in the unit test directory, right-click on the directory and select Run tests .
The Android Plugin for Gradle compiles the local unit test code located in the default directory (src/test/java), builds a test app, and executes it locally using the default test runner class. Android Studio then displays the results in the Run window.

Run Instrumented Tests

To run your instrumented tests:
  • In the Project window, navigate to your instrumented test class or method, then right-click and run it using the Android Test configuration. To run all tests in the instrumented test directory, right-click the directory and select Run tests .
The Android Plugin for Gradle compiles the instrumented test code located in the default directory (src/androidTest/java), builds a test APK and production APK, installs both APKs on the connected device or emulator, and runs the tests. Android Studio then displays the results of the instrumented test execution in the Run window.

Run Instrumented Tests with Cloud Test Lab

Using Cloud Test Lab, you can simultaneously test your app on many popular Android devices, across multiple languages, screen orientations, and versions of the Android platform. These tests run on actual physical devices in remote Google data centers. You can also configure your instrumented tests to take screenshots while Cloud Test Lab runs its tests. You can deploy tests to Cloud Test Lab from the command line, or from Android Studio's integrated testing tools.
Android Studio allows you to connect to your Google Cloud Platform account, configure your tests, deploy them to Cloud Test Lab, and analyze the results all within the development environment. Cloud Test Lab in Android Studio supports the following Android test frameworks: Espresso, UI Automator 2.0, or Robotium. Test results provide test logs and include the details of any app failures.
Before you can start using Cloud Test Lab, you need to:
  1. Create a Google Cloud Platform account to use with active billing.
  2. Create a Google Cloud project for your app.
  3. Set up an active billing account and associate it with the project you just created.

Configure a test matrix and run a test

Android Studio provides integrated tools that allow you to configure how you want to deploy your tests to Cloud Test Lab. After you have created a Google Cloud project with active billing, you can create a test configuration and run your tests:
  1. Click Run > Edit Configurations from the main menu.
  2. Click Add New Configuration (+) and select Android Tests.
  3. In the Android Test configuration dialog:
    1. Enter or select the details of your test, such as the test name, module type, test type, and test class.
    2. From the Target drop-down menu under Deployment Target Options, select Cloud Test Lab Device Matrix.
    3. If you are not logged in, click Connect to Google Cloud Platform and allow Android Studio access to your account.
    4. Next to Cloud Project, click the wrench and nut button and select your Google Cloud Platform project from the list.
  4. Create and configure a test matrix:
    1. Next to the Matrix Configuration drop-down list, click Open Dialog ellipses button.
    2. Click Add New Configuration (+).
    3. In the Name field, enter a name for your new configuration.
    4. Select the device(s), Android version(s), locale(s) and screen orientation(s) that you want to test your app with. Cloud Test Lab will test your app against every combination of your selections when generating test results.
    5. Click OK to save your configuration.
  5. Click OK in the Run/Debug Configurations dialog to exit.
  6. Run your tests by clicking Run .

Figure 1. Creating a test configuration for Cloud Test Lab.

Analyzing test results

When Cloud Test Lab completes running your tests, the Run window will open to show the results, as shown in figure 2. You may need to click Show Passed  to see all your executed tests.

Figure 2. Viewing the results of instrumented tests using Cloud Test Lab.
You can also analyze your tests on the web by following the link displayed at the beginning of the test execution log in the Run window, as shown in figure 3.

Figure 3. Click the link to view detailed test results on the web.
To learn more about interpreting web results, see Analyzing Cloud Test Lab Web Results.