Tag: AWS Device Farm


Test User Interfaces in iOS Apps with XCTest UI and AWS Device Farm

by Asha Chakrabarty | on | | Comments

With AWS Device Farm, you can quickly start testing your Android, iOS, and FireOS apps on real devices in the AWS Cloud. Choose to start an interactive session with a device or run automated tests on many devices at once. AWS Device Farm will provide the results of your tests including pass/fail status, logs, performance metrics, screenshots, and videos.

Introduction to XCTest UI

As of Xcode 7, you can access UI testing capabilities (XCUI) integrated into the Xcode IDE. This functionality allows you to find and interact with UI elements in your app and confirm their properties and states. A few new features make it possible for you to programmatically test and exercise the UI of an iOS app with:

  • New Xcode target type for UI tests:

To set up a UI test in Xcode, you create an Xcode target with the iOS UI Testing Bundle template. The Xcode target type fulfills the special requirements required by the UI tests, including launching a proxy for the application in a separate process and providing accessibility permissions.

  • UI testing APIs include three key classes:

    • XCUIElementQuery: Every UI element is backed by the ability to query its properties. For this reason, each XCUIElement must be unique.
    • XCUIElement: A proxy object for a UI element that is represented as types (for example, a cell or a button).
    • XCUIApplication: An instantiation of your application object that forms the origin for finding UI elements.
  • UI recording:

This allows you to record interactions with your app’s user interface. Xcode will transform these interactions into source code that can be included in your existing tests or to create new tests. 

AWS Device Farm now allows you to run the UI Testing feature incorporated in Xcode 7 on real devices in the AWS Cloud. In this post, we will walk you through how to create an XCTest UI test, package it for testing on AWS Device Farm, schedule a run, and view test results from real devices in the cloud.

Prerequisites

  • You’ll find the sample iOS app used in this post on AWS Labs on GitHub.
  • UI Testing was introduced in Xcode 7 and iOS 9, so be sure to update accordingly.
  • iOS devices must be enabled for development and connected to a host running Xcode.
  • It is assumed that you have created the .ipa file for the sample iOS app before you schedule a run in AWS Device Farm.

Step 1: Create a UI Test for the AWS Sample iOS App

After you have downloaded and opened the sample app in Xcode, build the project. After the build is successful, you will create a new a target type for the UI tests.

Your project navigator should look like the following:

With UI testing, you can record interactions within your app and Xcode will write the code required to re-enact those interactions in your test. You will still need to use XCTAssert to add your test assertions. You can record interactions with your UI by pressing the record button (the small red dot at the bottom left corner of the editor pane).

Copy the following UI test code to your AWSDeviceFarmiOSReferenceAppUITests.m implementation file.

#import 

@interface AWSDeviceFarmiOSReferenceAppUITests : XCTestCase

@end

@implementation AWSDeviceFarmiOSReferenceAppUITests

- (void)setUp {
    
    [super setUp];
    self.continueAfterFailure = NO;
    [[[XCUIApplication alloc] init] launch];
    
}


- (void)tearDown {
    
    [super tearDown];
}


- (void)testNativeInput {
    
    XCUIApplication *app = [[XCUIApplication alloc] init];
    XCUIElementQuery *tabBarsQuery = app.tabBars;
    [tabBarsQuery.buttons[@"Native"] tap];
    
    XCUIElementQuery *collectionViewsQuery = app.collectionViews;
    [collectionViewsQuery.staticTexts[@"Table of elements"] tap];
    [app.navigationBars[@"ElementsTableView"].buttons[@"Menu"] tap];
    [collectionViewsQuery.staticTexts[@"Scrolling View"] tap];
    [app.navigationBars[@"Scrolling View"].buttons[@"Menu"] tap];
    [tabBarsQuery.buttons[@"Home"] tap];
    
}


- (void)testNestedView {
    
    
    XCUIApplication *app = [[XCUIApplication alloc] init];
    XCUIElementQuery *tabBarsQuery = app.tabBars;
    [tabBarsQuery.buttons[@"More"] tap];
    [app.staticTexts[@"Nested"] tap];
    
    XCUIElement *moreNavigationBar = app.navigationBars[@"More"];
    XCUIElement *nextButton = moreNavigationBar.buttons[@"Next"];
    [nextButton tap];
    [nextButton tap];
    [nextButton tap];
    
    XCUIElement *backButton = [[[moreNavigationBar childrenMatchingType:XCUIElementTypeButton] matchingIdentifier:@"Back"] elementBoundByIndex:0];
    [backButton tap];
    [backButton tap];
    [backButton tap];
    [moreNavigationBar.buttons[@"More"] tap];
    [tabBarsQuery.buttons[@"Home"] tap];
    
}


- (void)testAlertControl {
    
    
    XCUIApplication *app = [[XCUIApplication alloc] init];
    XCUIElementQuery *tabBarsQuery = app.tabBars;
    [tabBarsQuery.buttons[@"More"] tap];
    [app.staticTexts[@"Alerts"] tap];
    [app.buttons[@"Modal"] tap];
    [app.buttons[@"OK"] tap];
    [app.buttons[@"Alert"] tap];
    [app.alerts[@"Alert"].collectionViews.buttons[@"OK"] tap];
    [app.navigationBars[@"More"].buttons[@"More"] tap];
    [tabBarsQuery.buttons[@"Native"] tap];
    [app.collectionViews.staticTexts[@"Image Gallery"] tap];
        
}

@end

Before packaging your test for AWS Device Farm, be sure to build the project with Xcode. Use the Product/Build for Running option select an iOS device. Keep in mind that the Build Active Architecture setting for your app and your UI test targets should be the same.

Step 2: Package Your Test for AWS Device Farm

When packaging your test for upload to AWS Device Farm, make sure your iOS XCTest UI Runner test runner bundle is contained in a correctly formatted .ipa file. For more information, see the AWS Device Farm documentation. You can also view the creation of an .ipa file on AWS Labs on GitHub.

Make sure that you package your test in the Payload folder under debug-iphoneos as shown here. In the following screenshot, we renamed the resulting zip file of the Payload folder to UITest.ipa for easier file management.

Step 3: Schedule a Run in AWS Device Farm

Sign in to the AWS Device Farm console and create a run under a new or existing project. Upload the .ipa file of the sample app.

In the next step, you will choose XCTest UI as the test type and upload the .ipa file you created in step 2.

Select the devices on which you’d like to test. If you like, you can create a new device pool for your test run to reuse in subsequent runs.

Finally, review and start the test run.

Step 4: View XCTest UI Test Results

When your test run is complete, you will see the test results summary.

Choose a device to examine its test suites. Here we are reviewing the test suite results for an Apple iPhone 5s and Apple iPhone 6 device.

The results for each device will contain screenshots, video recordings, performance data, and log files that can be downloaded for further review.

Conclusion

We are always happy to hear your feedback. Feel free to leave your feedback, including questions, in the comments or on our developer forum.

Happy testing!

Test iOS apps on AWS Device Farm using Appium – Part 3: Upload your iOS Application and TestNG tests to AWS Device Farm

by Asha Chakrabarty | on | | Comments

With AWS Device Farm, you can quickly get started testing your Android, iOS, and FireOS apps on real devices in the AWS cloud. Simply upload your app, choose your test framework and the devices you want to test your app on, and start your test run. AWS Device Farm will provide the results of your tests including pass / fail status, logs, performance characteristics, and screenshots.

Previously in Part 1 and Part 2 of this series, you set up your environment, created and validated your TestNG tests, and packaged your TestNG tests for upload to AWS Device Farm. In Part 3, you will upload the sample iOS app (an unsigned ipa file you downloaded as part of the prerequisities section in Part 1) and the TestNG package you created in Part 2.

Upload the sample iOS app and TestNG suite to AWS Device Farm

We now have the sample iOS app (ToDoList.ipa) you downloaded and the TestNG package (zip-with-dependencies.zip) that contains our test code and test dependencies. To begin testing iOS apps on AWS Device Farm, you will need an .ipa (iOS app archive) file, which you will upload to AWS Device Farm. Make sure when you create your own iOS apps, your .ipa file is built for an iOS device and not for a simulator. You do not need to add any UDIDs to your profile as Device Farm will resign your app automatically (See the FAQ for more info).

Follow the Getting Started steps to begin testing with AWS Device Farm. You will upload the iOS app (.ipa file), configure your test type (choose Appium with TestNG), and upload the zip-with-dependencies file that was created as part of the Maven build in Part 2 of this series.

Log into your AWS Account and navigate to the AWS Device Farm console under the Mobile Services category.

Create a new project if you do not have an existing one. A project is a logical workspace for your test runs.

Once you have created a project, click on it and create a run. A run represents a test of a specific build of your app, with a specific set of tests, to be run on a specific set of devices. Each test run will produce a report containing information about the results of the run. 

Browse to the location of the ipa file you downloaded in Part 1 and upload.

Once the app has successfully uploaded, proceed to configure the test type. For this example, we will select Appium Java TestNG. Note that the Appium Java TestNG framework is currently in preview mode. 

Upload the zip-with-dependencies zip file that was created in Part 2 of this series. This can be found in the “target” folder of the Maven project in the workspace location where you have stored your Eclipse projects.

Select the devices that are compatible with the app for testing. For this example, we will use a curated list of devices called Top Devices that AWS Device Farm has pre-selected for us. You have the option of selecting other devices by creating a new device pool.

The next step prompts you to specify device states to override any device settings. This allows you to provide additional data and / or install additional apps for AWS Device Farm to use during the run, specify whether Wi-Fi, Bluetooth, GPS, or NFC will be enabled during the run, preset the device latitude and longitude for the run, and preset the device locale for the run.

Choose "Review and start run." On the Review and start run page, choose "Confirm and start run" once you have confirmed all details. When your tests have completed, you will be able to drill down into each device to view the results.

If we click on the first device (Apple iPhone 5c), we can see that our TestNG test suites passed successfully and how much time it took for each to complete.

Based on the TestNG test suite we created in Part 1, you can see that each method that is part of the "com.aws.devicefarm.example.appiumiostest.SampleAppiumTestNGTest" package has been executed. Further if we click on the package name, you will see the four test cases that were created using the Appium Inspector. For each test case, you can view associated screenshots and download log files.

When you click on the "Screenshots" tab, any screenshots that were included in "test01" will be seen.

When you go to the "Files" tab, you will see a list of log files that have been generated for the "test01" test. You can click on each log file and download it for review.

Summary

By utilizing AWS Device Farm, you can test your iOS apps across multiple devices in parallel and get results in minutes to quickly understand your app’s behavior on popular devices. Now that you have an understanding of the steps involved in testing your iOS apps with Appium on AWS Device Farm, I’d highly encourage you to begin testing your own iOS apps. No modifications are required to your app or test code – just package your tests, upload, and start testing!

If you have questions or comments, please reach out to us in the comments section below or on our developer forum. We are happy to receive your feedback on AWS Device Farm and how to make testing iOS apps more seamless for you.

Happy Testing!

Test iOS apps on AWS Device Farm using Appium – Part 2: Packaging your TestNG test suite for AWS Device Farm

by Asha Chakrabarty | on | | Comments

With AWS Device Farm, you can quickly get started testing your Android, iOS, and FireOS apps on real devices in the AWS cloud. Simply upload your app, choose your test framework and the devices you want to test your app on, and start your test run. AWS Device Farm will provide the results of your tests including pass / fail status, logs, performance characteristics, and screenshots.

Previously in Part 1, we focused on the prerequisites and creation of the TestNG test suite. In this article, Part 2 of the three-part series, we will walk through how to package your test suite for uploading to AWS DeviceFarm. Before uploading your test suite to AWS Device Farm, the test suite should be packaged correctly and contain all the required dependencies. Both the tests and associated dependencies must be packaged as a zip file. In Part 3, we will upload the package from this post and run the tests on AWS Device Farm.

Package your TestNG Test Suite

Create a new Maven project in Eclipse using the quickstart archetype (maven-archetype-quickstart). It is recommended to match the Group Id / Artifact Id with the root package as shown in the sample pom.xml. For this sample, our package name is com.aws.devicefarm.example.appiumiostest.

Copy the TestNG class created in the previous step to your Maven project under src/test/java.

Save the following XML assembly to src/main/assembly/zip.xml. The following XML is an assembly definition that, when configured, instructs Maven to build a .zip file containing everything in the root of your build output directory and the dependency-jars directory.

	<assembly

	    xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"

	    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	    xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">

	      <id>zip</id>

	      <formats>

	            <format>zip</format>

	      </formats>

	      <includeBaseDirectory>false</includeBaseDirectory>

	      <fileSets>

	            <fileSet>

	                  <directory>${project.build.directory}</directory>

	                  <outputDirectory>./</outputDirectory>

	                  <includes>

	                    <include>*.jar</include>

	                  </includes>

	            </fileSet>

	            <fileSet>

	                  <directory>${project.build.directory}</directory>

	                  <outputDirectory>./</outputDirectory>

	                  <includes>

	                    <include>/dependency-jars/</include>

	                  </includes>

	            </fileSet>

	      </fileSets>

	</assembly>

Replace your pom.xml with the following (NOTE: Change the groupId, artifactId, and name elements to match that of your Maven project).

	<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

	  <modelVersion>4.0.0</modelVersion>

	

	  <groupId>com.aws.devicefarm.example</groupId>

	  <artifactId>appiumiostest</artifactId>

	  <version>0.0.1-SNAPSHOT</version>

	  <packaging>jar</packaging>

	  <name>appiumiostest</name>

	  <url>http://maven.apache.org</url>

	

	  <properties>

	    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

	  </properties>

	  <dependencies>

	        <dependency>

	            <groupId>org.testng</groupId>

	            <artifactId>testng</artifactId>

	            <version>6.8.8</version>

	            <scope>test</scope>

	        </dependency>

	        <dependency>

	            <groupId>org.seleniumhq.selenium</groupId>

	            <artifactId>selenium-java</artifactId>

	            <version>2.42.2</version>

	        </dependency>

	        <dependency>

	            <groupId>io.appium</groupId>

	            <artifactId>java-client</artifactId>

	            <version>1.4.0</version>

	        </dependency>

	  </dependencies>

	  <build>

	        <plugins>

	            <plugin>

	                <groupId>org.apache.maven.plugins</groupId>

	                <artifactId>maven-jar-plugin</artifactId>

	                <version>2.6</version>

	                <executions>

	                    <execution>

	                        <goals>

	                            <goal>test-jar</goal>

	                        </goals>

	                    </execution>

	                </executions>

	            </plugin>

	            <plugin>

	                <groupId>org.apache.maven.plugins</groupId>

	                <artifactId>maven-dependency-plugin</artifactId>

	                <version>2.10</version>

	                <executions>

	                    <execution>

	                        <id>copy-dependencies</id>

	                        <phase>package</phase>

	                        <goals>

	                            <goal>copy-dependencies</goal>

	                        </goals>

	                        <configuration>

	                            <outputDirectory>${project.build.directory}/dependency-jars/</outputDirectory>

	                        </configuration>

	                    </execution>

	                </executions>

	            </plugin>

	            <plugin>

	                <artifactId>maven-assembly-plugin</artifactId>

	                <version>2.5.4</version>

	                <executions>

	                    <execution>

	                        <phase>package</phase>

	                        <goals>

	                            <goal>single</goal>

	                        </goals>

	                        <configuration>

	                            <finalName>zip-with-dependencies</finalName>

	                            <appendAssemblyId>false</appendAssemblyId>

	                            <descriptors>

	                                <descriptor>src/main/assembly/zip.xml</descriptor>

	                            </descriptors>

	                        </configuration>

	                    </execution>

	                </executions>

	            </plugin>

	        </plugins>

	  </build>

	</project>

Build, package, and verify your Maven project using the following command.

mvn clean package –DskipTests=true

The Maven project structure should look similar to the below. Note the zip-with-dependencies file that was created under the “target” folder. This contains our test code with all dependencies:

Summary

Now that we have packaged our tests and have a sample iOS app to test, in Part 3 we will upload both to AWS Device Farm to test across multiple devices and receive test results within minutes. Feel free to post any suggestions, comments or questions in the comments section below or in our developer forum. We look forward to hearing your feedback.

Test iOS apps on AWS Device Farm using Appium – Part 1: Prerequisities, Environment Set Up, and Test Creation

by Asha Chakrabarty | on | | Comments

With AWS Device Farm, you can quickly get started testing your Android, iOS, and FireOS apps on real devices in the AWS cloud. Simply upload your app, choose your test framework and the devices you want to test your app on, and start your test run. AWS Device Farm will provide the results of your tests including pass / fail status, logs, performance metrics, and screenshots.

The objective of this three-part series is to walk through step-by-step how to get started testing an iOS app with AWS Device Farm. The test automation framework we will be using is Appium and we will write our test cases using the TestNG framework. We will not be building an iOS app as part of this walkthrough. However, to follow along with this post, a sample iOS app is available for download here.

At the end of this series, you will have the knowledge required to test an iOS app with AWS Device using Appium and TestNG.

Prerequisites

For this example, the tools and versions listed below were used. It is assumed you have these tools installed on your machine beforehand and that you have an AWS Account.

  • Java 8
  • Eclipse IDE Mars was used for this tutorial.
  • m2e Maven Integration for Eclipse
  • Xcode 7.0 We will use a sample, unsigned iOS app called “ToDoList.ipa” that you can download here.
  • Appium 1.4.8 If you have not worked with Appium before, please review the Appium documentation before moving ahead.  We will be using the Appium GUI for this tutorial.  Please install the latest version of the Appium GUI.
  • Apache Maven 3.3.3 Or the latest version of Maven
  • AWS Account and IAM User creation Follow steps under the Setting Up section of the AWS Device Farm documentation.

A preamble on Appium

Appium is a test automation framework that executes your test suite across both iOS and Android apps without you having to further modify your app or create separate test suites for the same app. Appium is able to provide this capability by utilizing Selenium WebDriver, which follows a client-server protocol. Appium uses Selenium WebDriver to be able to receive commands from a client running your tests and respond to those commands with a response over HTTP. This follows a request / response paradigm in which requests are the commands being sent to the Appium server and responses are being received by the client via WebDriver. 

Appium executes your tests as described below:

  1. Tests for an iOS or Android app are written in a WebDriver-supported programming language. Appium provides client-side libraries for many languages. 
  2. An Appium server is launched after installation and configuration on the test machine.
  3. The tests are initiated on a client machine.
  4. Appium will begin receiving commands from the client (the machine running your tests) and execute those commands (your test emulating user actions with your app) on an emulator or real device.

Now that we have walked through the prerequisites and an overview of Appium, let’s get started building out our test cases for the sample iOS app you have downloaded.

Create a Java project in Eclipse

Launch Eclipse and create a new Java project to begin writing your test cases by selecting File -> New -> Java Project.

Create two source folders: src/main/java and src/test/java. Within each source folder, create a package in which you will eventually create your TestNG test class. Your project structure should look similar to the below.

Configure the build path for each source folder by right clicking the source folder and selecting ‘Configure Build Path.’ Ensure you have selected the Java Build Path option from the left hand menu and you are on the Source tab. Check the ‘Allow output folders for source folders’ option.

  1. For src/main/java -> the output folder is target/classes.
  2. For src/test/java -> the output folder is target/test-classes.

The build paths for your source folders should look similar to the folders in the image below.

Add external libraries for Selenium WebDriver, TestNG, and Appium Java Client

Selenium

Download the Selenium Client & WebDriver Language Bindings for the language of your choice. For this tutorial, we will be using Java.  Downloads are available at: http://docs.seleniumhq.org/download/.

  1. Once you have saved and unzipped the Selenium dependencies to your machine, right-click the Java project created in Step 1 and go to Properties.  
  2. Select Java Build Path in the left-hand menu and ensure you are on the Libraries tab. Select ‘Add External JARS’ and navigate to the location of your Selenium jar files. 
  3. Select the 2 Selenium jar files and the jar files in the folder ‘libs’ and click ‘Apply.’

TestNG

To install TestNG in Eclipse, go to Help -> Eclipse Marketplace -> Search for TestNG and Install.

Once you have installed TestNG in Eclipse, proceed below:

  1. Right click on the project created in Step 1 and go to Properties. 
  2. Select Java Build Path in the left-hand menu and ensure you are on the Libraries tab. Select the ‘Add Library’ button on the right.
  3. Select TestNG -> Next -> Finish.
  4. Select ‘Apply’ and then click OK.

Appium client for Java

Download the Appium client library for Java and add the jar file to the project you created in Step 1. Follow steps as performed when adding the Selenium jar files.

Once all referenced libraries have been added to your Java project, your project structure should look similar to the image below.

Create the TestNG test suite

Create a Java class called "SampleAppiumTestNGTest" under src/test/java for creating your TestNG test code. Paste the below sample TestNG code:

package com.aws.devicefarm.example.appiumiostest;

import org.testng.annotations.Test;
import java.io.File;
import java.net.URL;
import org.openqa.selenium.By;
import org.openqa.selenium.OutputType;
import org.openqa.selenium.TakesScreenshot;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;

public class SampleAppiumTestNGTest 
{
	private static RemoteWebDriver driver = null;
	
	public boolean takeScreenshot(final String name) {
		String screenshotDirectory = System.getProperty("appium.screenshots.dir", System.getProperty("java.io.tmpdir", ""));
		File screenshot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE)
		return screenshot.renameTo(new File(screenshotDirectory, String.format("%s.png", name)));
	}
  
	
	@BeforeMethod
	public void setUp() throws Exception {
		DesiredCapabilities capabilities = new DesiredCapabilities();
       		URL url = new URL("http://localhost:4723/wd/hub");
        	driver = new RemoteWebDriver(url, capabilities);
	}
	
	
	@Test
	public void test01() throws InterruptedException {
		driver.findElement(By.name("Add")).click();
		driver.findElement(By.xpath("//UIAApplication[1]/UIAWindow[1]/UIATextField[1]")).sendKeys("Complete Taxes");
		driver.findElement(By.name("Save")).click();
		driver.findElement(By.xpath("//UIAApplication[1]/UIAWindow[1]/UIATableView[1]/UIATableCell[4]")).click();
		String screenshot1 = null;
		takeScreenshot(screenshot1);
	}
	
	
	@Test
	public void test02() throws InterruptedException {
		driver.findElement(By.name("Add")).click();
		driver.findElement(By.xpath("//UIAApplication[1]/UIAWindow[1]/UIATextField[1]")).sendKeys("Book tickets for vacation");
		driver.findElement(By.name("Save")).click();
		String screenshot2 = null;
		takeScreenshot(screenshot2);
	}
	

	@Test
	public void test03() throws InterruptedException {
		driver.findElement(By.name("Add")).click();
		driver.findElement(By.xpath("//UIAApplication[1]/UIAWindow[1]/UIANavigationBar[1]/UIAButton[1]")).click();
	}
	

	@Test
	public void test04() throws InterruptedException {
		driver.findElement(By.xpath("//UIAApplication[1]/UIAWindow[1]/UIATableView[1]/UIATableCell[1]")).click();
		driver.findElement(By.xpath("//UIAApplication[1]/UIAWindow[1]/UIATableView[1]/UIATableCell[1]")).click();
		driver.findElement(By.xpath("//UIAApplication[1]/UIAWindow[1]/UIATableView[1]/UIATableCell[1]")).click();
	}

	
	@AfterMethod
	public static void tearDownClass() {
        		if (driver != null) {
            		driver.quit();
        		}
    	}
}

To capture the user interface elements and interactions in the TestNG test suite, Appium Inspector was used. To do this yourself, you can launch the Appium GUI and select the iOS Settings.

  1. For the App Path, navigate to the location of your .app file. 
  2. Ensure you check the Force Device option and choose a device.
  3. Ensure a Platform Version is selected.
  4. Click the Launch button.
  5. Click the icon with the magnifying glass to launch the Appium Inspector.
  6. Begin recording your tests.

NOTE:  Appium versions 1.4.11 and later support Xcode 7 with iOS 9 simulators. To use the Appium Inspector for capturing elements in this case, you will need to point the Appium client GUI to the latest Appium version. To do this:

  1. Clone the Appium git to your local git clone (https://github.com/appium/appium.git)
  2. Once the download is complete, Run reset.sh
  3. Open the Appium client (GUI)
  4. Select "Developer settings" and enable it
  5. Select Use External NodeJS Binary to "Your local node bin folder path"
  6. Select Use External Appium Package to "Your Appium Local clone folder path"
  7. Launch the Appium Server

Summary

You should now have your environment set up, a sample iOS app that you downloaded, and an Eclipse project with your TestNG tests.  With this you can run your test suite locally with Appium and validate your tests. Join us in Part 2 where we will walk through how to prepare your TestNG test suite for uploading to AWS Device Farm. Finally, in Part 3 we will run the tests we’ve created in the AWS Cloud with AWS Device Farm. We are always interested in your feedback, comments, and questions so please reach out to us in the comments section below or in our developer forum.

 

Set Up Continuous Testing with Appium, AWS CodeCommit, Jenkins, and AWS Device Farm

by Epshteyn, Ilya | on | | Comments

AWS Device Farm is an app testing service that enables you to test your native, hybrid, and web apps on real Android and iOS devices hosted in the AWS Cloud. A test report containing high-level results, low-level logs, pixel-to-pixel screenshots, and performance data is updated as tests are completed.

The purpose of this walkthrough is to show how AWS Device Farm can be integrated into a continuous testing process to expose application risks with each build, enabling the development team to prevent problems from progressing to the next stage of the software development lifecycle. In this walkthrough, we will be leveraging the Appium automation framework for Android (Java based), AWS CodeCommit as our source control service, a Jenkins server for continuous builds, and AWS Device Farm to test against real mobile devices. 

Pre-requisites

Below are the pre-requisites for getting started:

Configure your Appium Maven project

In this walkthrough, we will be configuring a Java based Appium Maven project. If you don’t have an existing Appium Maven project in Eclipse, you can use the following sample project available on GitHub. Simply Download the project zip, extract it to a local directory, and import into Eclipse (File –> Import –> Maven –> Existing Maven Project). 

Before going to the next step, make sure you can get a clean Maven build within Eclipse. To create a Maven build, simply right click on pom.xml and select Run As –> Maven build.

In the Edit Configuration dialog, specify “clean install” as Goals and click Run.

A zip-with-dependencies file will be generated in the target sub-folder if the build is successful:

Set up AWS CodeCommit and configure EGit

Create an AWS CodeCommit Repository

First create an AWS CodeCommit repository using the AWS CodeCommit Console or AWS CLI. Note the SSH URL of your repository as this will be needed in a following step:

Configure SSH Authentication for your CodeCommit repository

We will be using SSH credentials for accessing CodeCommit from EGit. Please use the following walkthroughs for setting up SSH credentials on Windows or OS X environments (you may skip Step 2 and Step 4, but make sure to test your SSH credentials in Step 3 before proceeding further).

Create a local clone of your AWS CodeCommit repository

The next step is to create a local clone of your AWS CodeCommit repository to be used with your Appium project. In Eclipse, open the Git Repositories view (Window –>  Show View –>  Other –> Git –> Git Repositories) and click on Clone a Git repository link. In the Clone Git Repository dialog box, select Clone URI option and click Next:

Paste the AWS CodeCommit SSH URL as the URI. The Host and Repository path fields will be auto-populated. Select ssh as the Protocol and click Next

A warning message will appear on the next screen stating that the Source Git Repository is empty. Click Next to continue. On the next dialog, configure the local storage for the repository and click Finish.

Now right click on your Appium Maven project and select Team –> Share Project.

In the Repository dropdown, select the repository you have just cloned and press Finish.

Right click again on your Appium Maven project and select Team –> Commit.  Add a commit message, select all files and click Commit.

Right click one more time on your Maven project and select Team –> Push branch ‘master’ to push the branch to your AWS CodeCommit repository. Click Next and Finish on the following two dialogs. A Push Results dialog will confirm a succesful push to the CodeCommit repository.

You may also login to AWS CodeCommit console to confirm that the repo has been updated:

Configure Jenkins

Install Jenkins server

If you don’t already have a Jenkins server, you can install one very quickly and easily on an Amazon Linux AMI using the following instructions:

  1. If setting up a new Jenkins serer, create an Amazon EC2 service role and attach a managed policy AWSCodeCommitPowerUser to it. Jenkins will use the permissions granted by the IAM role to access the CodeCommit repositories.
  2. Launch an Amazon Linux AMI and login to your instance.
  3. Update your repositories: sudo yum update
  4. Get Jenkins repository: sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo
  5. Get Jenkins repository key: sudo rpm –import http://pkg.jenkins-ci.org/redhat-stable/jenkins-ci.org.key
  6. Install Jenkins server: sudo yum install jenkins
  7. Start Jenkins server: sudo service jenkins start
  8. Make sure the Jenkins server starts up automatically: sudo chkconfig jenkins on
  9. Open your browser and navigate to http://<Server-IP>:8080. You should see the Jenkins dashboard.
  10. Secure Jenkins server by selecting “Manage Jenkins” on the Jenkins dashboard and click on “Configure Global Security”.  Check “Enable Security” and select the desired Access Control and Authorization. 

Install Jenkins plugins

  1. Login to Jenkins
  2. Navigate to Manage Jenkins, Manage Plugins, and then choose the following plugins: aws-device-farm, Git plugin, and Copy To Slave Plugin and click Save.
  3. Navigate to Jenkins Dashboard and select Manage Jenkins and then Configure System.  Scroll down to Maven section and click Add Maven. Enter any name for the Maven installation and click Save to automatically configure the Maven installation.
  4. Restart Jenkins

Configure the AWS Device Farm Jenkins plugin

Once your Jenkins server is up and running, install the AWS Device Farm Jenkins Plugin following these steps. You will then create an IAM user and Policy with DeviceFarmAll permissions that will be used by the plugin to submit Runs to the AWS Device Farm service.

Configure access to your CodeCommit respository

  • SSH to the Jenkins server.Install Git: sudo yum install git
  • If you are using Amazon Linux AMI for your Jenkins server the AWS CLI is already pre-installed. If you are not using Amazon Linux AMI, install AWS CLI.
  • Configure the AWS CLI for the jenkins user. 
   cd ~jenkins
   sudo -u jenkins aws configure

Specify the AWS Access Key ID and AWS Secret Access Key for a user that has permissions to the CodeCommit repository you created earlier. If you are using an EC2 service role, leave the AWS Access Key ID and AWS Secret Access Key blank. Jenkins will use the permissions granted by the IAM role to access the CodeCommit repositories.

   AWS Access Key ID [None]: paste the Access Key ID, and then press Enter
   AWS Secret Access Key [None]: paste the Secret Access Key, and then press Enter
   Default region name [None]: type us-east-1, and then press Enter
   Default output format [None]: type json, and then press Enter
  • Next, configure Git on the Jenkins server to use IAM credentials and an HTTP path to access the repositories hosted by AWS CodeCommit.
   sudo -u jenkins git config --global credential.helper '!aws codecommit credential-helper $@'
   sudo -u jenkins git config --global credential.useHttpPath true
   sudo -u jenkins git config --global user.email "me@mycompany.com"
   sudo -u jenkins git config --global user.name "MyJenkinsServer"
  • Restart Jenkins server

Configure your Jenkins project with CodeCommit and Device Farm

From the Jenkins home page, select New Item. Type a project name and select a Maven project and click OK:

In the Source Code Management section, select Git and paste the HTTP endpoint of your CodeCommit repository. 

You can get the HTTP endpoint of your CodeCommit repository in the AWS CodeCommit console:

For the Build Trigger, select Poll SCM and specify a schedule, for instance H/05 * * * *

In the Build Environment section, select Copy files into the job’s workspace before building and specify the name of the Android application file such as “app-debug.apk." This file needs to be uploaded to $JENKINS_HOME/userContent directory on the Jenkins server before the build is triggered. Alternatively, you can include the application file within your Appium Maven project within Eclipse, depending on your development and testing workflow.

In the Post Steps section, select Run Tests on AWS Device Farm under the Add post-build action dropdown:

In the Run Tests on AWS Device Farm section, specify the following parameters:

  • Project: select the name of the Device Farm Project.
  • Device Pool: select a default Top Devices pool or another device pool that you have created previously.
  • Application: specify the name of the Android application file such as “app-debug.apk” (either included in your Appium Maven Project or copied to the workspace as specified in the Build Environment section above)
  • Choose test to run: select Appium Java TestNG and specify target/zip-with-dependencies.zip which is the Maven build output file containing all of the tests.

Click Save to save your Jenkins project configuration.

Trigger an automatic test run on Device Farm

Make an update to your Appium Maven Project in Eclipse, commit the changes and push the branch to AWS CodeCommit repository. After a few minutes you should see a Jenkins build in progress:

You can also navigate to Console Output to confirm a successful Maven build and a scheduled Device Farm run:

Return to the build status page and click on the Full Report link to automatically login to the AWS Device Farm console to view detailed statistics for the run and artifacts including detailed logs and screenshots.

Conclusion

In this tutorial we demonstrated how AWS Device Farm can be integrated into your Continuous Testing strategy. First, we showed how an Appium Maven project can be pushed to AWS CodeCommit repository. Then, by leveraging Jenkins, we configured a project that automatically triggers a Maven build and submits Appium tests to Device Farm for testing against hundreds of real mobile devices. If you have questions, please let us know in the comments section or in our developer forum.

Get started with the AWS Device Farm CLI and Calabash Part 2: Retrieving Reports and Artifacts

by Epshteyn, Ilya | on | | Comments

In Part 1 of the walkthrough, we went through the process of creating an AWS Device Farm run for Calabash-Android test scripts.  In the second and final part of the series, we will go through the CLI commands for obtaining the status of the run and to retrieve all of the artifacts associated with a run including log files and screenshots.

Device Farm Run Components

Before we begin, let’s review the hierarchical structure of a Device Farm run:

  • RUN – A run in Device Farm represents a specific build of your app, with a specific set of tests, to be run on a specific set of devices. A run produces a report that contains information about the test execution. A run contains one or more jobs.
  • JOB – A job is a request to test a single app against a single device. A job contains one or more suites.
  • SUITE – A suite is a hierarchical organization of tests in a test package. A suite contains one or more tests.
  • TEST – A test is an individual test within a suite. This is the most granular entity in Device Farm’s data hierarchy.

 

Retrieving Reports and Artifacts

Using Device Farm CLI, we can obtain the status and result counters for each level of the run hierarchy including run, job, suite, and test. As you’ll see, the data available for each level of the hierarchy is very similar, with the scope of the data becoming more granular as you navigate deeper in the hierarchy.

Step 1: Retrieve the Status and Result Counters for a Device Farm Run

Use the get-run CLI command to retrieve the status and result counters of the run. 

[ec2-user]$  aws devicefarm get-run –arn arn:aws:devicefarm:us-west-2:705582597265:run:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917

Output:

{
    "run": {
        "status": "COMPLETED",
        "name": "firstCLIRun",
        "created": 1443331615.166,
        "totalJobs": 101,
        "completedJobs": 101,
        "platform": "ANDROID_APP",
        "result": "ERRORED",
        "billingMethod": "METERED",
        "type": "CALABASH",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:run:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917",
        "counters": {
            "skipped": 37,
            "warned": 16,
            "failed": 46,
            "stopped": 0,
            "passed": 514,
            "errored": 66,
            "total": 679
        }
    }
}

The above Run has a total of 101 jobs corresponding to 101 unique devices, all of which have completed.  This Run also has 679 individual tests with 46 failures and 66 errors.


Step 2: Retrieve the Status and Counters for all Jobs within a Run:

Use the list-jobs CLI command to list all jobs within a run along with job-level status and result counters.

[ec2-user]$  aws devicefarm list-jobs –arn arn:aws:devicefarm:us-west-2:705582597265:run:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917

Output (partial):

{
    "jobs": [
        {
            "status": "COMPLETED",
            "name": "ASUS Nexus 7 – 2nd Gen (WiFi)",
            "created": 1443331616.586,
            "result": "PASSED",
            "device": {
                "formFactor": "TABLET",
                "name": "ASUS Nexus 7 – 2nd Gen (WiFi)",
                "resolution": {
                    "width": 1200,
                    "height": 1920
                },
                "image": "NA",
                "platform": "ANDROID",
                "heapSize": 0,
                "memory": 34359738368,
                "model": "Nexus 7 – 2nd Gen",
                "os": "4.3.1",
                "cpu": {
                    "frequency": "MHz",
                    "architecture": "ARMv7",
                    "clock": 1512.0
                },
                "arn": "arn:aws:devicefarm:us-west-2::device:208FE7EE973042EA97DEC2EEF31CD10A",
                "manufacturer": "ASUS"
            },
            "message": "Successful test lifecycle of Setup Test",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:job:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066",
            "counters": {
                "skipped": 0,
                "warned": 0,
                "failed": 0,
                "stopped": 0,
                "passed": 7,
                "errored": 0,
                "total": 7
            }
        },
        {
            "status": "COMPLETED",
            "name": "Amazon Kindle Fire HDX 7 (WiFi)",
            "created": 1443331615.56,
            "result": "FAILED",
            "device": {
                "formFactor": "TABLET",
                "name": "Amazon Kindle Fire HDX 7 (WiFi)",
                "resolution": {
                    "width": 1920,
                    "height": 1200
                },
                "image": "NA",
                "platform": "ANDROID",
                "heapSize": 0,
                "memory": 17179869184,
                "model": "Kindle Fire HDX 7",
                "os": "4.4.3",
                "cpu": {
                    "frequency": "MHz",
                    "architecture": "ARMv7",
                    "clock": 2150.0
                },
                "arn": "arn:aws:devicefarm:us-west-2::device:BC44B6802F134918BDAB6FB4F38C37CC",
                "manufacturer": "Amazon"
            },
        "message": "I see the text "In Theaters" failed: Timeout waiting for elements: * {text CONTAINS[c] ‘In Theaters’} (Calabash::Android::WaitHelpers::WaitError)",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:job:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00018",
            "counters": {
                "skipped": 0,
                "warned": 0,
                "failed": 5,
                "stopped": 0,
                "passed": 2,
                "errored": 0,
                "total": 7
            }
        }

Note the hierarchical nature of the ARN.  The ARN type is “job” and the job ID is appended to the Run ARN: arn:aws:devicefarm:us-west-2:705582597265:job:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066


Step 3: Retrieve the Status and Result Counters for all Suites within a Job:

Use the list-suites CLI command to list all Suites within a job along with suite-level status and result counters.

[ec2-user]$  aws devicefarm list-suites –arn arn:aws:devicefarm:us-west-2:705582597265:job:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066

Output (partial)

    "suites": [
        {
            "status": "COMPLETED",
            "name": "Setup Suite",
            "created": 1443331656.183,
            "result": "PASSED",
            "message": "Successful test lifecycle of Setup Test",
            "arn": "arn:aws:devicefarm:us-west-2:705582597265:suite:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066/00000",
            "counters": {
                "skipped": 0,
                "warned": 0,
                "failed": 0,
                "stopped": 0,
                "passed": 1,
                "errored": 0,
                "total": 1
            }
        },
        {
            "status": "COMPLETED",
            "name": "STARmeter",
            "created": 1443331656.221,
            "result": "PASSED",
            "message": "Given I see the text "In Theaters" passed",
            "arn": "arn:aws:devicefarm:us-west-2:705582597265:suite:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066/00001",
            "counters": {
                "skipped": 0,
                "warned": 0,
                "failed": 0,
                "stopped": 0,
                "passed": 1,
                "errored": 0,
                "total": 1
            }
        }

The returned ARN type is “suite” and the suite ID is appended to the end: arn:aws:devicefarm:us-west-2:705582597265:suite:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066/00006
 

Step 4: Retrieving the Status and Result Counters for all Tests within a Suite

Use the list-tests CLI command to list all tests within a suite along with test-level status and result counters.

[ec2-user]$  aws devicefarm list-tests –arn arn:aws:devicefarm:us-west-2:705582597265:suite:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066/00006

Output:

{
    "tests": [
        {
            "status": "COMPLETED",
            "name": "Teardown Test",
            "created": 1443331656.424,
            "result": "PASSED",
            "message": "Successful test lifecycle of Teardown Test",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:test:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066/00006/00000",
            "counters": {
                "skipped": 0,
                "warned": 0,
                "failed": 0,
                "stopped": 0,
                "passed": 1,
                "errored": 0,
                "total": 1
            }
        }
    ]
}

The returned ARN type is “test” and the Test ID is appended to the end of the ARN": "arn:aws:devicefarm:us-west-2:705582597265:test:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066/00006/00000
 

Step 5: Retrieving the Artifacts for a Run, Job, Suite or Test

Using the list-artifacts CLI command, you can retrieve all of the artifacts associated with any of the levels of the run by specifying the corresponding ARN.  For example:

  • List artifacts for the run by specifying the run ARN:
    [ec2-user]$  aws devicefarm list-artifacts –arn arn:aws:devicefarm:us-west-2:705582597265:run:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917 –type FILE
  • List artifacts for the job by specifying the job ARN:
    [ec2-user]$  aws devicefarm list-artifacts –arn arn:aws:devicefarm:us-west-2:705582597265:job:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066 –type FILE
  • List artifacts for the suite by specifying the suite ARN:
    [ec2-user]$  aws devicefarm list-artifacts –arn arn:aws:devicefarm:us-west-2:705582597265:suite:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066/00000 –type FILE
  • List artifacts for the individual test by specifying the test ARN:
    [ec2-user]$  aws devicefarm list-artifacts –arn arn:aws:devicefarm:us-west-2:705582597265:test:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066/00006/00000 –type FILE

Note that there are three types of artifacts available: FILE, LOG and SCREENSHOT.

The output of the list-artifacts CLI command will include a pre-signed S3 URL that you can use to securely download the artifact:

{
    "artifacts": [
        {
            "url": "https://prod-us-west-2-results.s3-us-west-2.amazonaws.com/705582597265/2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066/00000/00000/3d811922-64d2-4d0c-8195-ffb715300836.logcat?AWSAccessKeyId=AKIAI3BDGZ5S7TQL2OZA&Expires=1446165402&Signature=D02sc66m01XXYtSJV0hVGK4l9aA%3D",
            "extension": "logcat",
            "name": "Logcat",
            "arn": "arn:aws:devicefarm:us-west-2:705582597265:artifact:2c21a412-bb7b-4657-a28c-d7d78b3888f7/16b3ce7d-63de-4371-bbc7-fdcb20b3f917/00066/00000/00000/00000"
        }
    ]
}

 

Conclusion

In this two-part series we have demonstrated the use of the AWS CLI to submit a Calabash-Android test script to Device Farm for testing against real mobile devices.  We have also demonstrated the use of the CLI to retrieve the status of the test Run as well as to retrieve the reports and artifacts for your test Run. If you have questions, please let us know in the comments section or in our developer forum.

Get started with the AWS Device Farm CLI and Calabash Part 1: Creating a Device Farm Run for Android Calabash Test Scripts

by Epshteyn, Ilya | on | | Comments

AWS Device Farm is an app testing service that enables you to test your native, hybrid, and web apps on real Android and iOS devices that are hosted in the AWS Cloud. A test report containing high-level results, low-level logs, pixel-to-pixel screenshots, and performance data is updated as tests are completed.

Device Farm allows you to upload your own tests or use built-in, script-free compatibility tests. Because testing is automatically performed in parallel, test results are available in minutes. Device Farm supports native and hybrid Android, iOS, and Fire OS apps, including those created with PhoneGap, Titanium, Xamarin, Unity, and other frameworks. It also supports testing web apps in Chrome on Android and Safari on iOS. You can run Built-in-Fuzz tests and Explorer tests or utilize your favorite testing framework including Appium, Calabash, Espresso, and UI Automation. 

The purpose of this walkthrough is to show you how you can quickly submit Calabash test scripts to AWS Device Farm leverageing the AWS Command Line Interface (CLI) for Device Farm. Although the walkthrough uses an Android application and Calabash, you can follow the same steps to test iOS and web apps, as well as use one of the many supported frameworks.

Key Concepts

Before we get started, let’s review a few key AWS Device Farm concepts:

  • PROJECT – A project in Device Farm enables you to organize your tests in whatever way you choose. For example, there can be one project per app title, or there can be one project per platform. You can create as many projects as you need.
  • RUN – A run in Device Farm represents a specific build of your app, with a specific set of tests, to be run on a specific set of devices.
  • DEVICE POOL – A device pool is a pre-configured set of devices that can be used as part of a run. 

Scheduling a Device Farm Run Using the CLI

Prerequisite: Before you can create a run in Device Farm, you must install the AWS Command Line Interface (CLI).

Once you install the CLI, there are five steps to create a Calabash test run in AWS Device Farm:

  1. Create a Device Farm project
  2. Upload your application (Android APK file)
  3. Upload your Calabash test scripts
  4. Create a device pool
  5. Schedule a run

Step 1: Create a Device Farm Project

The first step is to create a Device Farm project. You can also use an existing project if you’ve already created one.

[ec2-user]$  aws devicefarm create-project –name adndroidTest

Output:

[ec2-user@ip-10-0-19-179 ~]$ aws devicefarm create-project –name calabashCLI
{
    "project": {
        "name": "calabashCLI",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:project:2c21a412-bb7b-4657-a28c-d7d78b3888f7",
        "created": 1442719623.245
    }
}

Note the project ARN as you will reference it when creating your run in the upcoming steps.

Step 2: Create an Upload for Your Android APK File

AWS Device Farm leverages Amazon’s secure and durable S3 service for uploading all objects required for the run.  The upload process utilizes S3 pre-signed URLs to assure a secure upload.

The first step in the upload process is to create your upload request and obtain the S3 pre-signed upload URL:

[ec2-user]$  aws devicefarm create-upload –project-arn arn:aws:devicefarm:us-west-2:705582597265:project:2c21a412-bb7b-4657-a28c-d7d78b3888f7 –name IMDb_5.4.1.105410410_105410410.apk –type ANDROID_APP

The –project-arn is the ARN of your project that you created in Step1: Create a Device Farm Project.

Output:

{
    "upload": {
        "status": "INITIALIZED",
        "name": "IMDb_5.4.1.105410410_105410410.apk",
        "created": 1442719884.445,
        "url": "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/arn%3Aaws%3Adevicefarm%3Aus-west-2%3A705582597265%3Aproject%3A2c21a412-bb7b-4657-a28c-d7d78b3888f7/uploads/arn%3Aaws%3Adevicefarm%3Aus-west-2%3A705582597265%3Aupload%3A2c21a412-bb7b-4657-a28c-d7d78b3888f7/d1f8bebc-a7f5-49a3-881f-f1ffdae90303/IMDb_5.4.1.105410410_105410410.apk?AWSAccessKeyId=AKIAI3BDGZ5S7TQL2OZA&Expires=1442806284&Signature=HZYPvpPBQn%2FTo%2BWmdSx1LW1nOwE%3D",
        "type": "ANDROID_APP",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:upload:2c21a412-bb7b-4657-a28c-d7d78b3888f7/d1f8bebc-a7f5-49a3-881f-f1ffdae90303"
    }
}

The pre-signed URL is returned as the url output parameter.

The second step is to upload the actual APK file using the S3 pre-signed URL:

[ec2-user]$  curl -T IMDb_5.4.1.105410410_105410410.apk "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/arn%3Aaws%3Adevicefarm%3Aus-west-2%3A705582597265%3Aproject%3A2c21a412-bb7b-4657-a28c-d7d78b3888f7/uploads/arn%3Aaws%3Adevicefarm%3Aus-west-2%3A705582597265%3Aupload%3A2c21a412-bb7b-4657-a28c-d7d78b3888f7/d1f8bebc-a7f5-49a3-881f-f1ffdae90303/IMDb_5.4.1.105410410_105410410.apk?AWSAccessKeyId=AKIAI3BDGZ5S7TQL2OZA&Expires=1442806284&Signature=HZYPvpPBQn%2FTo%2BWmdSx1LW1nOwE%3D"

You can check the status of your APK upload using the get-upload CLI command. Specify the ARN returned in the create-upload request above.

[ec2-user]$  aws devicefarm get-upload –arn arn:aws:devicefarm:us-west-2:705582597265:upload:2c21a412-bb7b-4657-a28c-d7d78b3888f7/d1f8bebc-a7f5-49a3-881f-f1ffdae90303

Output:

{
    "upload": {
        "status": "SUCCEEDED",
        "name": "IMDb_5.4.1.105410410_105410410.apk",
        "created": 1442719884.445,
        "type": "ANDROID_APP",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:upload:2c21a412-bb7b-4657-a28c-d7d78b3888f7/d1f8bebc-a7f5-49a3-881f-f1ffdae90303",
        "metadata": "{"screens": ["small", "normal", "large", "xlarge"], "sdk_version": "14", "package_name": "com.imdb.mobile", "native_code": [], "target_sdk_version": "18", "version_name": "5.4.1.105410410", "version_code": "105410410", "activity_name": "com.imdb.mobile.HomeActivity"}"
    }
}

Once the status is "SUCCEEDED" you are ready to continue to Step 3.

Step 3: Create an Upload for Your Calabash Test Package

In this step, you will upload the Calabash test scripts package. Please refer to the documentation on how to prepare your Android Calabash test package for upload to Device Farm.

The upload process for Calabash test scripts is similar to the upload of the Android APK file in Step 2.

First create an upload request and obtain the S3 pre-signed upload URL:

[ec2-user]$  aws devicefarm create-upload –project-arn arn:aws:devicefarm:us-west-2:705582597265:project:2c21a412-bb7b-4657-a28c-d7d78b3888f7 –name features.zip –type CALABASH_TEST_PACKAGE

Output:

{
    "upload": {
        "status": "INITIALIZED",
        "name": "features.zip",
        "created": 1442724498.222,
        "url": "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/arn%3Aaws%3Adevicefarm%3Aus-west-2%3A705582597265%3Aproject%3A2c21a412-bb7b-4657-a28c-d7d78b3888f7/uploads/arn%3Aaws%3Adevicefarm%3Aus-west-2%3A705582597265%3Aupload%3A2c21a412-bb7b-4657-a28c-d7d78b3888f7/ccfa27c9-3f66-49ac-abe0-542214cd650c/features.zip?AWSAccessKeyId=AKIAI3BDGZ5S7TQL2OZA&Expires=1442810898&Signature=MOGwu7vUP3q%2B8OrrlSmJ5nVsQe0%3D",
        "type": "CALABASH_TEST_PACKAGE",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:upload:2c21a412-bb7b-4657-a28c-d7d78b3888f7/ccfa27c9-3f66-49ac-abe0-542214cd650c"
    }
}

Next, upload the Calabash text package ZIP file to the S3 pre-signed URL:

[ec2-user]$  curl -T features.zip "https://prod-us-west-2-uploads.s3-us-west-2.amazonaws.com/arn%3Aaws%3Adevicefarm%3Aus-west-2%3A705582597265%3Aproject%3A2c21a412-bb7b-4657-a28c-d7d78b3888f7/uploads/arn%3Aaws%3Adevicefarm%3Aus-west-2%3A705582597265%3Aupload%3A2c21a412-bb7b-4657-a28c-d7d78b3888f7/ccfa27c9-3f66-49ac-abe0-542214cd650c/features.zip?AWSAccessKeyId=AKIAI3BDGZ5S7TQL2OZA&Expires=1442810898&Signature=MOGwu7vUP3q%2B8OrrlSmJ5nVsQe0%3D"

You can check the status of your Calabash test package upload using the get-upload CLI command. Specify the upload ARN returned in the create-upload request above.

[ec2-user]$  aws devicefarm get-upload –arn arn:aws:devicefarm:us-west-2:705582597265:upload:2c21a412-bb7b-4657-a28c-d7d78b3888f7/ccfa27c9-3f66-49ac-abe0-542214cd650c

Output:
{
    "upload": {
        "status": "SUCCEEDED",
        "name": "features.zip",
        "created": 1442724498.222,
        "type": "CALABASH_TEST_PACKAGE",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:upload:2c21a412-bb7b-4657-a28c-d7d78b3888f7/ccfa27c9-3f66-49ac-abe0-542214cd650c",
        "metadata": "{"valid": true}"
    }
}

Once the status is "SUCCEEDED" you are ready to continue to Step 4.

Step 4: Create a Device Pool Associated with the Project

The AWS Device Farm fleet currently includes over 200 different Android, Fire OS, and iOS devices (see the current device list). You may create Device Pools that consist of specific set of devices that you would like to test against. Your device pools can consist of static lists of devices or rule-based on multiple parameters including device platform (i.e. Android or iOS), manufacturer, and form factor.

The CLI command below creates a Device Pool consisting of all available Android devices:

[ec2-user]$  aws devicefarm create-device-pool –project-arn arn:aws:devicefarm:us-west-2:705582597265:project:2c21a412-bb7b-4657-a28c-d7d78b3888f7 –name myAndroidDevicePool –rules ‘[{"attribute": "PLATFORM", "operator": "EQUALS", "value": ""ANDROID""}]’

Output:

{
    "devicePool": {
        "rules": [
            {
                "operator": "EQUALS",
                "attribute": "PLATFORM",
                "value": ""ANDROID""
            }
        ],
        "name": "myAndroidDevicePool",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:devicepool:2c21a412-bb7b-4657-a28c-d7d78b3888f7/e4a54fbd-d094-4130-b6d9-60811820e4d8"
    }
}

Step 5: Schedule a Run

To schedule a run, you will need the following input parameters:

  • project-arn: the ARN of the project from Step1: Create a Device Farm Project
  • app-arn: the ARN of the Application upload from Step 2: Create an Upload for Your Android APK File
  • testPackageArn: the ARN of the Calabash test package upload from Step 3: Create an Upload for Your Calabash Test Package
  • device-pool-arn: the ARN of the device pool created in Step 4: Create a Device Pool Associated with the Project

The following command schedules a run in Device Farm using the specified Android application, Calabash test package, and device pool:

[ec2-user]$  aws devicefarm schedule-run –project-arn arn:aws:devicefarm:us-west-2:705582597265:project:2c21a412-bb7b-4657-a28c-d7d78b3888f7 –app-arn arn:aws:devicefarm:us-west-2:705582597265:upload:2c21a412-bb7b-4657-a28c-d7d78b3888f7/d1f8bebc-a7f5-49a3-881f-f1ffdae90303 –device-pool-arn arn:aws:devicefarm:us-west-2:705582597265:devicepool:2c21a412-bb7b-4657-a28c-d7d78b3888f7/e4a54fbd-d094-4130-b6d9-60811820e4d8 –name firstCLIRun –test ‘{"type": "CALABASH","testPackageArn":"arn:aws:devicefarm:us-west-2:705582597265:upload:2c21a412-bb7b-4657-a28c-d7d78b3888f7/ccfa27c9-3f66-49ac-abe0-542214cd650c"}’

Output:

{
    "run": {
        "status": "SCHEDULING",
        "name": "firstCLIRun",
        "created": 1442724966.821,
        "totalJobs": 100,
        "completedJobs": 0,
        "platform": "ANDROID_APP",
        "result": "PENDING",
        "billingMethod": "METERED",
        "type": "CALABASH",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:run:2c21a412-bb7b-4657-a28c-d7d78b3888f7/61c16425-15c8-4fba-a44f-07dcba60f717",
        "counters": {
            "skipped": 0,
            "warned": 0,
            "failed": 0,
            "stopped": 0,
            "passed": 0,
            "errored": 0,
            "total": 0
        }
    }
}

You can check the status of the run by using the get-run CLI command:

[ec2-user]$  aws devicefarm get-run –arn arn:aws:devicefarm:us-west-2:705582597265:run:2c21a412-bb7b-4657-a28c-d7d78b3888f7/61c16425-15c8-4fba-a44f-07dcba60f717

Output:

{
    "run": {
        "status": "COMPLETED",
        "name": "firstCLIRun",
        "created": 1442724966.821,
        "totalJobs": 100,
        "completedJobs": 100,
        "platform": "ANDROID_APP",
        "result": "ERRORED",
        "billingMethod": "METERED",
        "type": "CALABASH",
        "arn": "arn:aws:devicefarm:us-west-2:705582597265:run:2c21a412-bb7b-4657-a28c-d7d78b3888f7/61c16425-15c8-4fba-a44f-07dcba60f717",
        "counters": {
            "skipped": 37,
            "warned": 17,
            "failed": 65,
            "stopped": 0,
            "passed": 495,
            "errored": 65,
            "total": 679
        }
    }
}

Once the status is "COMPLETED" your tests on all devices have completed and a full, aggregate summary is available. More on that in Part 2 of this series.

Conclusion

As you can see it’s easy to test your application on dozens of real mobile devices using the Device Farm CLI. Join us in Part 2 of this series where you will retrieve the status and artifacts for your Device Farm Run, including an aggregate summary, log files, and screenshots. If you have any questions please leave a comment below or reach out in our developer forum.

Getting started with Android testing on AWS Device Farm using Espresso – Part 3: Uploading your Android application to AWS Device Farm

by Richard Threlkeld | on | | Comments

AWS Device Farm is a service that allows you to test your Android, Fire OS, and iOS apps on real devices (not emulators or simulators) in the AWS Cloud. You can upload your apps to the cloud and run Fuzz tests to simulate random activity or leverage the built-in app explorer, which crawls your app and captures screenshots as well as performance metrics and logs. To take further advantage of the service you’ll need to leverage one of the supported test automation frameworks. That’s where this series of blog posts comes in.

In Part One and Part Two of this series you created a basic Android application and configured it to use Espresso for running automated tests and taking screenshots. Now that you have your development and build environment setup you can upload the app to AWS Device Farm.

Upload into Device Farm

Log onto your AWS Account and under Mobile Services select Device Farm. You may be prompted to change to the US West (Oregon) Region.

Click "Getting Started" or the "Create a new project" button if you have an existing Project. Call the Project "Espresso Test."

Go into the Project and select "Create a new Run." Choose the "Upload" button to browse to the APK file that Android Studio generated.

Depending on your operating system, the output location for the APK file will be different. In this simple example we have built an unsigned application for testing purposes on OSX so the default location will be something like:

/Users/username/AndroidStudioProjects/SimpleDemoApp/app/build/outputs/apk

Notice in this directory there will be an "app-debug.apk." This is the file we will upload here but take note of the "app-debug-androidTest-unaligned.apk" file as it will be used next.

Once you upload this file and it is processed by Device Farm you will see a message similar to below.

Press next and select "Instrumentation" as the test type. Again, press the "Upload" button. However, this time select the "app-debug-androidTest-unaligned.apk" file. This is where Android Studio has placed the test cases you created in the project structure before. Once the file uploads successfully you will see the Test Package information and Runner displayed.

If you wanted to you have the capability to apply a test filter and run a single test case rather than an entire suite. This can be very helpful if you have resolved an issue and don’t need to retest an entire suite during development. For this tutorial we will leave the filter blank.

On the next screen you will see a list of devices that your application has compatibility. If you wish you can create a custom device pool or accept the default list of devices.

Press "Next step" and take note of the device state options. If you wanted to on this screen you could modify things such as latitude/longitude, locale, radio states, or install other applications – perhaps if you would like to test dependencies on other apps.

One more thing worth pointing out is your ability to “Add extra data." A good use case for this would be an application, which is quite large and leverages an APK Expansion File. If you have an application that makes use of this capability then this would be the time for you to upload your zip file to the Test Run.

Click "Review and start run." Then, assuming everything looks okay, click "Confirm and start run" to begin testing your application. After a moment you will be able to click on the run and see some initial results. Click on one of the devices such as a Samsung Galaxy S6 (Verizon).

Note the package names in the Test Suite. Click on "com.example.simpledemoapp.EspressoTest" and you will see the "testEspresso" method you created earlier as well as some logging details in the lower pane. Clear the "Source" filter by clicking the "X" next to "Harness" and you will see all of the messages including the logcat messages from your code listed. To filter more specifically you can use wildcards in the "Message" field as seen below.

You can also download the raw logs by clicking on the "Files" tab at the top of the screen and process these files using the tools of your choice.

Finally click the "Screenshots" tab and you will see an image that looks like what you saw earlier when running the sample application locally in your emulator.

Conclusion

That concludes this series on getting started with Android test automation using Espresso and AWS Device Farm. Hopefully you now have the foundation to write your own tests that exercise the functionality and business logic of your Android apps. For additional pointers and sample code for Espresso and other frameworks, check out our sample Android app and tests on GitHub.  If you have questions or comments please join us in the comment section below.

Getting started with Android testing on AWS Device Farm using Espresso – Part 2: Setting up Espresso and taking screenshots

by Richard Threlkeld | on | | Comments

AWS Device Farm is a service that allows you to test your Android, Fire OS, and iOS apps on real devices (not emulators or simulators) in the AWS Cloud. You can upload your apps to the cloud and run Fuzz tests to simulate random activity or leverage the built-in app explorer, which crawls your app and captures screenshots as well as performance metrics and logs. To take further advantage of the service you’ll need to leverage one of the supported test automation frameworks. That’s where this series of blog posts comes in.

In Part One of this series you created a basic application. Now, in Part Two, you will create test cases in Espresso to validate functionality and take screenshots before uploading to the AWS Cloud. In Part Three you will run your app and tests in the AWS Cloud with AWS Device Farm. Let’s get started.

Gradle

Open the build.gradle for the app in the main navigation bar.

Replace the text with the following:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 22
    buildToolsVersion "22.0.1"

    defaultConfig {
        applicationId "com.example.simpledemoapp"
        minSdkVersion 19
        targetSdkVersion 22
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
    packagingOptions{
        exclude 'LICENSE.txt'
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:22.1.1'
    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.0'
}

Save your changed file. On the right hand side of Android Studio you will see a tab called "Gradle." Click it and then right-click the root item and select "Refresh external project."

Expand SimpleDemoApp/SimpleDemoApp/Tasks/build and double-click “assembleAndroidTest."

Next, switch to the "Tests" view in the Project navigator.

Expand app/app/src/androidTest/java until you get to the com/example/simpledemoapp package structure.

Right-click the package and select New->Java Class. Type “EspressoTest” for the name and click OK.

Replace the contents of the file with the below code:

package com.example.simpledemoapp;

import android.test.ActivityInstrumentationTestCase2;

import static android.support.test.espresso.Espresso.onView;
import static android.support.test.espresso.action.ViewActions.click;
import static android.support.test.espresso.action.ViewActions.typeText;
import static android.support.test.espresso.assertion.ViewAssertions.matches;
import static android.support.test.espresso.matcher.ViewMatchers.withId;
import static android.support.test.espresso.matcher.ViewMatchers.withText;

public class EspressoTest extends ActivityInstrumentationTestCase2 {

    public EspressoTest() {super(SimpleDemoActivity.class);}

    @Override
    public void setUp() throws Exception {
        super.setUp();
        getActivity();
    }

    public void testEspresso(){
        onView(withId(R.id.editText)).perform(typeText("Testing with AWS Device Farm
        onView(withId(R.id.buttonUpdate)).perform(click());
        onView(withId(R.id.updatedText)).check(matches(withText("Testing with AWS Device Farm")));
    }
}

Save the file.

In the top navigation bar select Run->Edit Configurations.

Click the plus (+) sign to add an Android Test configuration node. Click on that node and press plus again to add a new configuration for EspressoTest. Ensure that the Class matches and the Instrumentation Runner is android.support.test.runner.AndroidJUnitRunner.

Now Right-Click the EspressoTest class in the navigation pane->Run->EspressoTest.

If everything runs successfully you will see the test run in the emulator. You might need to click fast to bring it in focus.

Also you should see “Done 1 of 1” in the Run section of the console for successful test execution with Espresso.

IMPORTANT: If you created a test in your Class and your output doesn’t match the above screenshot, or you get a message such as “No test events received,” it may be due to how you named the test. Tests must start with the name “test” such as “testEspresso()” in the above example or the test runner will not recognize them.

Screenshots

At this point we have a very basic application that technically can be uploaded and tested in Device Farm. However, according to the documentation we need to save screenshots to the SD Card in order for them to be seen after a Run. If the Espresso .check() call fails we would like to see a screenshot of what the screen looked like in order to troubleshoot.

To accomplish this task we’ll create a utility class that will save PNG files to /sdcard/test-screenshots/ as per the Device Farm documentation. The class will take an input of the Activity and a string identifier for the file name.

Select File->New->Java Class and when prompted name it "ScreenShot." IMPORTANT: This name must be precise including capitalization so use a capital "S."

Paste in the following code:

package com.example.simpledemoapp;

import android.app.Activity;
import android.graphics.Bitmap;
import android.os.Environment;
import android.util.Log;
import android.view.View;

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStream;

public class ScreenShot {
    private static final String TAG = "SCREENSHOT_TAG";

    public static void take(Activity activity, String name) {
        final String dir = Environment.getExternalStorageDirectory().getAbsolutePath() + "/test-screenshots/";
        final String path = dir + name;

        File filePath = new File(dir);     // Create directory if not present
        if (!filePath.isDirectory()) {
            Log.i(TAG, "Creating directory " + filePath);
            filePath.mkdirs();
        }

        Log.i(TAG, "Saving to path: " +  path);

        View phoneView = activity.getWindow().getDecorView().getRootView();
        phoneView.setDrawingCacheEnabled(true);
        Bitmap bitmap = Bitmap.createBitmap(phoneView.getDrawingCache());
        phoneView.setDrawingCacheEnabled(false);

        OutputStream out = null;

        File imageFile = new File(path);

        try {
            out = new FileOutputStream(imageFile);
            bitmap.compress(Bitmap.CompressFormat.PNG, 100, out);
            out.flush();
        }
        catch (FileNotFoundException e) {
            Log.e(TAG, e.toString());
        }
        catch (IOException e) {
            Log.e(TAG, e.toString());
        }

        finally {
            try {
                if (out != null) {
                    out.close();
                }
            } catch (IOException e) {
                Log.e(TAG, e.toString());
            }
        }
    }
}

Now modify testEspresso()in the EspressoTest.java class to make a call to the newly created ScreenShot class:

public void testEspresso() throws IOException {

    Log.i("TESTESPRESSO", "Starting the Espresso Test");
    onView(withId(R.id.editText)).perform(typeText("Testing with AWS Device Farm
    onView(withId(R.id.buttonUpdate)).perform(click());
    onView(withId(R.id.updatedText)).check(matches(withText("Testing with AWS Device Farm")));

    // Take the screenshot
    ScreenShot.take(getActivity(),"Homepage");

}

You will also need to modify the AndroidManifest.xml file so that your application has permission to write and read from the SD card. In the Project Navigator expand app/src/main and double-click AndroidManifest.xml. Add in the "uses-permission" entries as in the example XML below.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.simpledemoapp" >

    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme" >
        <activity
            android:name=".SimpleDemoActivity"
            android:label="@string/app_name" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

</manifest>

Run the test again in the emulator but this time after it finishes open the Android Device Monitor from the Android Studio task bar.

In the Android Device Monitor you will find a tab called "File Explorer." Select this and navigate to /storage/sdcard/test-screenshots. If you see a file called "Homepage" then you have run everything successfully. If you wish you can click on the file and download the image for viewing.

Conclusion

That’s it for Part Two! Now join us for Part Three of this series where you will upload your application to AWS Device Farm and see your tests run across multiple devices in the AWS Cloud. If you have questions please join us in the comment section below.

Getting started with Android testing on AWS Device Farm using Espresso – Part 1: Building a sample application

by Richard Threlkeld | on | | Comments

AWS Device Farm is a service that allows you to test your Android, Fire OS, and iOS apps on real devices (not emulators or simulators) in the AWS Cloud. You can upload your apps to the cloud and run Fuzz tests to simulate random activity or leverage the built-in app explorer, which crawls your app and captures screenshots as well as performance metrics and logs. To take further advantage of the service you’ll need to leverage one of the supported test automation frameworks. That’s where this series of blog posts comes in.

In this three-part series we will show you how to create a basic Android application that leverages Espresso as a testing framework and runs tests across a pool of devices in the AWS Cloud. The application has a text entry field where the user can type information and a button so that when pressed the entered information shows on the screen. This can be thought of as a basic application feature that you’ll write an automated test in Espresso to validate.

In Part One you will create the application and run it locally. Part Two covers test creation and Part Three will cover cloud execution with Device Farm.

Prerequisites

This guide assumes that you have Android Studio installed with the Android SDK configured and you have a working emulator from the Android Virtual Device (AVD) Manager.

Open the SDK Manager and scroll down to “Extras” at the bottom. Ensure that the “Android Support Repository” is installed.

Gradle

If you are not already familiar with Gradle please take a moment to familiarize yourself before going any further: https://gradle.org/getting-started-android/

Android Studio

Start by creating a new Project in Android Studio. Name the application SimpleDemoApp.

Important: For this demo ensure the Company Domain is exactly like the image above.

For this example we used KitKat as the minimum SDK version but note Espresso will support previous versions as well. Select the Blank Activity template and change the Activity name to “SimpleDemoActivity”.

Click finish and the project will be created. Open the application’s main layout file (activity_simple_demo.xml).

If you don’t see the above go to View->Tool Windows->Project and use the navigation bar on the left.

Click the text view towards the bottom of Android Studio and replace the XML with the following:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent"
    android:layout_height="match_parent" android:paddingLeft="@dimen/activity_horizontal_margin"
    android:paddingRight="@dimen/activity_horizontal_margin"
    android:paddingTop="@dimen/activity_vertical_margin"
    android:paddingBottom="@dimen/activity_vertical_margin" tools:context=".MainActivity">

    <TextView android:text="Some Text!"
        android:id="@+id/updatedText"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

    <Button
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Click to update text"
        android:id="@+id/buttonUpdate"
        android:layout_below="@+id/updatedText"
        android:layout_alignParentStart="true" />

    <EditText
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:id="@+id/editText"
        android:layout_below="@+id/buttonUpdate"
        android:layout_alignParentStart="true"
        android:layout_marginTop="52dp"
        android:layout_alignParentEnd="true" />

</RelativeLayout>

Save the file. This will create an area to input text, a button, and an area to display the text. Now we need to wire up these objects to a controller. Open the main Activity class (SimpleDemoActivity.java) from the navigation pane.

Replace the contents with the following code:

package com.example.simpledemoapp;

import android.support.v7.app.ActionBarActivity;
import android.os.Bundle;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;

public class SimpleDemoActivity extends ActionBarActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_simple_demo);

        Button updateButton = (Button)findViewById(R.id.buttonUpdate);
        updateButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                TextView textToUpdate =
                    (TextView)findViewById(R.id.updatedText);
                EditText enteredText = (EditText)findViewById(R.id.editText);
                textToUpdate.setText(enteredText.getText().toString());
            }
        });

    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        // Inflate the menu; this adds items to the action bar if
        // it is present.
        getMenuInflater().inflate(R.menu.menu_simple_demo, menu);
        return true;
    }

    @Override
    public boolean onOptionsItemSelected(MenuItem item) {
        // Handle action bar item clicks here. The action bar will
        // automatically handle clicks on the Home/Up button, so long
        // as you specify a parent activity in AndroidManifest.xml.
        int id = item.getItemId();

        if (id == R.id.action_settings) {
            return true;
        }

        return super.onOptionsItemSelected(item);
    }
}

Save the file. Now run your application  either on an emulator or real device. When starting up an emulator this can take a few minutes. Once running, you should be able to input some text, click the button and have it show up on the screen.

Conclusion

That’s it for Part One! Now join us for Part Two of this series where you will modify this application to use Espresso for building test cases and take screen shots. If you have questions please join us in the comment section below.