AndroidDev Tips – Wiebe Elsinga

What’s new in Android Testing

W.Elsinga — Thu, 09 Apr 2015 02:20:09 +0000

During Droidcon Italy Stephan Linzner from Google explained upcoming features in the Android Testing Support Library. Lets have a closer look at some:

Test Filtering

If you want to suppress a test to run on certain target Api levels, just add the @SdkSuppress annotation.

@SdkSuppress(minSdkVersion=15)
@Test
public void featureWithMinSdk15() {
...
}

You can also filter tests to only run on a (physical) device by adding the @RequiresDevice annotation.

@RequiresDevice
@Test
public void SomeDeviceSpecificFeature() {
...
}

ActivityTestRule

Because ActivityInstrumentationTestCase2 will become deprecated you need to define a @Rule.

Rules allow very flexible addition or redefinition of the behavior of each test method in a test class

https://github.com/junit-team/junit/wiki/Rules

So in your test add a @Rule annotation, and create an ActivityTestRule for your Activity

@RunWith(AndroidJUnit4.class)
@LargeTest
public class ChangeTextBehaviorTest {
...

@Rule
public ActivityTestRule<MainActivity> mActivityRule = new ActivityTestRule<>(MainActivity.class);

@Test
public void changeText_sameActivity() {
// Type text and then press the button.
onView(withId(R.id.editTextUserInput)).perform(typeText(STRING_TO_BE_TYPED), closeSoftKeyboard());
onView(withId(R.id.changeTextBt)).perform(click());

// Check that the text was changed.
onView(withId(R.id.textToBeChanged)).check(matches(withText(STRING_TO_BE_TYPED)));
}
}

Now create your ActivityTestRule

public class ActivityTestRule<T extends Activity> {

public T getActivity() {}

protected Intent getActivityIntent() {}

protected void beforeActivityLaunched() {}

protected void afterActivityFinished() {}
}

Espresso-Intents

Espresso-Intents is like Mockito but for Intent, basically hermetic inter-app testing.
To give you an example, lets say in your application when a user presses a “call” button, you want to know if the correct data will be send to the Intent.ACTION_CALL.

So first create an IntentsTestRule and then verify that the Intent was sent using Espresso-Intents

@RunWith(AndroidJUnit4.class)
@LargeTest
public class DialerActivityTest {
...
@Rule
public IntentsTestRule<DialerActivity> mRule = new IntentsTestRule<>(DialerActivity.class);

@Test
public void typeNumber_ValidInput_InitiatesCall() {
onView(withId(R.id.edit_text_caller_number)).perform(typeText(VALID_PHONE_NUMBER),
closeSoftKeyboard());
onView(withId(R.id.button_call_number)).perform(click());

intended(allOf(
hasAction(is(equalTo(Intent.ACTION_CALL))),
hasData(equalTo(INTENT_DATA_PHONE_NUMBER)),
toPackage(PACKAGE_ANDROID_DIALER)));
}
}

So now you know…

All code can be found in android-testing github:

Thanks Stephan Linzner for the resources. #HappyTesting

The Hitchhiker’s guide to Android Testing, part 2: Espresso

W.Elsinga — Fri, 03 Apr 2015 02:04:02 +0000

As mentioned in the first article Ali Derbane and me wrote about Android Functional Testing, there are a lot of frameworks you can use. In this second part of the journey I will be explaining the functional testing framework called Espresso.

Introduction

Introduced at the GTAC in 2013, Espresso is designed to be used in environments where the developers write their own tests, and makes it possible to write concise, beautiful, and reliable Android UI tests quickly.
Espresso has several general components:

The Espresso class offers the onView and onData methods which, alone, can be used for a good numbers of possible tests on a given interface.
ViewMatchers contains a collection of objects that implements the interface Matcher <? super View>. Using this Class you can collect and check View elements. For example, getting a View element (Button) with text “7”.
ViewActions contains a collection of viewAction objects to perform actions on a view. These actions are passed to the method ViewInteraction.perform and may contain multiple actions. For example, clicking on a View element (Button).
ViewAssertions contains a collection of ViewAssertion to conduct checks on views.

To illustrate these components a test can look like this:

Espresso.onView(ViewMatchers.withText("7")).perform(ViewActions.click());
Espresso.onView(withId(R.id.result)).check(ViewAssertions.matches(ViewMatchers.withText("42")));

And the good news, as of last year Google has introduced a Testing Support Library containing Espresso. So lets start by implementing Espresso.

To illustrate, we are going to write some tests that tests agains a Android calculator application. The common test scenario we will be implementing is testing if ‘6’ x ‘7’ equals ‘42’.

Define the test runner

To use Espresso we first need to define who is running the tests. Espresso uses a new runner named AndroidJUnitRunner. This runner, based on InstrumentationTestRunner and GoogleInstrumentationTestRunner, runs JUnit3 and JUnit4 tests against your Android application.

First add the dependencies to your build.gradle, assuming you have installed the Testing Support Library.

dependencies {
androidTestCompile 'com.android.support.test:testing-support-lib:0.1'
}

Then add the runner in your build.gradleandroid.defaultConfig configuration:

defaultConfig {
...
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}

Writing the test

As you may know test classes must be in src\androidTest\com.example.package.tests, com.example.package being the package specified in the package attribute of the manifest element in the AndroidManifest file.
Also each test class must extend the abstract class ActivityInstrumentationTestCase2 and supply the Test Activity as generic type that will be used by default for testing.
It must also be passed to the superclass via the super(). To make the Test Activity being called by the test framework, simply define a setup which calls the synchronous method getActivity().

1
2
3
4
5
6
7
8
9
10
11
12

public class FunctionalInstrumentationTest extends ActivityInstrumentationTestCase2<ActivityToTest> {

public FunctionalInstrumentationTest() {
super(ActivityToTest.class);
}

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

As mentioned we want to check if ‘6’ x ‘7’ equals ‘42’.

1
2
3
4
5
6
7
8

public void testAnswer_to_the_Ultimate_Question_of_Life_the_Universe_and_Everything() {
onView(withText("7")).perform(click());
onView(withText("×")).perform(click());
onView(withText("6")).perform(click());
onView(withText("=")).perform(click());

onView(withId(R.id.resText)).check(matches(withText("42")));
}

You may have noticed, this example is using static imports. This is solely done to make the code more readable.

Other actions you want to use are:

pressBack(); to simulate the use of the “back” button,
isDisplayed(); to check if an element is being shown and
scrollTo(); to scroll to an element.

Running the test

Now lets do the fun part, lets run the test. This can be done from the command line with he command line with gradle connectedAndroidTest or using Android Studio by:

Open Run menu | Edit Configurations
Add a new Android Tests configuration
Choose the module you are testing
Define our test runner: android.support.test.runner.AndroidJUnitRunner

So now you know a bit more about Espresso. If you want to know more, you may want to visit:

Updated (08-04) When running the tests with gradle you can just use gradle connectedAndroidTest

Archive addition Android artifacts with Gradle.

W.Elsinga — Fri, 20 Mar 2015 06:42:19 +0000

When building Android applications or libraries common practice is to save your artifacts to a local file storage or repo.

Beside your APK there are some additional artifacts you want/need to save, and you want gradle to do this. Most common ones are Javadoc, your source files and perhaps your proguard generated files like the mapping file.

I naturally wanted a Gradle task to handle this. So lets have a look as some tasks you may want to use.

Adding Javadoc archive tasks

The following will add tasks to generate Javadocs for each build type and assemble it into a jar archive .

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

android.applicationVariants.all { variant ->
project.task("${variant.name.capitalize()}Javadoc", type: Javadoc) {

destinationDir = new File("$project.buildDir/javadoc/$variant.name")

source = variant.javaCompile.source

ext.androidJar = "${project.android.sdkDirectory}/platforms/${project.android.compileSdkVersion}/android.jar"
classpath = project.files(variant.javaCompile.classpath.files) + project.files(ext.androidJar)

options {
linksOffline("http://d.android.com/reference", "${project.android.sdkDirectory}/docs/reference")
links("http://docs.oracle.com/javase/7/docs/api/");
setMemberLevel(JavadocMemberLevel.PACKAGE)
docEncoding = 'UTF-8'
encoding = 'UTF-8'
charSet = 'UTF-8'
}

exclude '**/BuildConfig.java'
exclude '**/R.java'
}

project.task("generate${variant.name.capitalize()}JavadocJar", type: Jar, dependsOn: "${variant.name.capitalize()}Javadoc") {
classifier 'javadoc'

description = 'Assembles a jar archive containing the generated Javadoc API documentation of $variant.name.'

destinationDir = new File("$project.buildDir/libs/")

exclude '**/BuildConfig.class'
exclude '**/R.class'

from "$project.buildDir/javadoc/$variant.name"
}
}

When added to your build.gradle file, generate your Javadoc jar archive from the command line with gradle generateReleaseJavadocJar.

Adding Source archive tasks

The following will add tasks to assemble a jar archive containing the Java sources.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

android.applicationVariants.all { variant ->
project.task("generate${variant.name.capitalize()}SourcesJar", type: Jar) {
classifier = 'sources'

description = 'Assembles a jar archive containing the main sources of $variant.name..'

destinationDir = new File("$project.buildDir/libs/")

// exclude generated files
exclude '**/BuildConfig.java'
exclude '**/R.java'

from variant.javaCompile.source
}
}

When added to your build.gradle file, generate your Sources jar archive from the command line with gradle generateReleaseSourcesJar.

Adding Proguard archive tasks

The following will add tasks to assemble a zip archive containing the generated proguard files.

1
2
3
4
5
6
7
8
9
10

android.applicationVariants.all { variant ->
project.task("generate${variant.name.capitalize()}ProguardFilesJar", type: Zip) {
classifier 'proguard'

description = 'Assembles a jar archive containing the Proguard files of $variant.name..'

destinationDir = new File("$project.buildDir/libs/")
from "$project.buildDir/outputs/mapping"
}
}

When added to your build.gradle file, generate your Proguard zip archive from the command line with gradle generateReleaseProguardFilesJar.

AndroidDev (Pro) tip: Do not forget screenSize

W.Elsinga — Fri, 01 Feb 2013 08:34:52 +0000

So you are stuck using screenOrientation in your android:configChanges list within your AndroidManifest. Your activity will not be recreated, but will receive a callback instead.
You may not know that this is insufficient on API level of 13 or above.

In API level 13 or above, the screen size changes when the orientation changes, so this cause the activity to be destroyed. If you still want to keep the state and use onConfigurationChanged() you will also need to use screenSize.

AndroidDev (Pro) tip: Fragment meets container

W.Elsinga — Fri, 01 Feb 2013 08:04:58 +0000

Today a tip from my colleague Coen Houtman, a tip about Fragments and the container to put them in. What all of you Fragment users know, is that you must have a container (i.e. ViewGroup) to put your fragments in.

Which ViewGroup is the best to use?

Normally, with any other layout I want to create, I start with a LinearLayout. It’s simple, easy and lightweight; something that you will experience in more complex layouts. If you use LinearLayout as the container for your Fragments, you will probably run into some issues. In the image below, the content doesn’t even take up half the screen. Even though the width was set to match it’s parent.

The solution to the problem above: use FrameLayout! I’m not claiming that FrameLayout is always the way to go. In all our projects though, we use FrameLayout as the container for our Fragments. At the moment I don’t have the answer of why FrameLayout works better than LinearLayout. But when I do, you’ll read it here!