Things are getting pretty exciting ๐ as we work our way through learning espressoโs API
In the last part Hello, espresso! Part 2 Working with lists, we learned how to work with list controls (RecyclerView
, AdapterView
) in espresso. Go ahead and have a read in case you missed it.
Learning to test Intents ๐ช
In this post, weโll understand how to automate testing of intents using espresso.
espresso-intents
provides us the capabilities to validate intents for a couple of important use cases:
- Test whether the correct intent is invoked with valid data by our app
- Or, even stub out the intents sent out so that we can verify only our apps logic (while assuming other apps that we depend upon have been tested independently)
What is an Android intent?
Indeveloper.android.comโs post about Android Intents
An intent is an abstract description of an operation to be performed.
It can be used:
- with
startActivity
to launch an Activity,broadcastIntent
to send it to any interestedBroadcastReceiver
components,- and
Context.startService(Intent)
orContext.bindService(Intent, ServiceConnection, int)
to communicate with a background Service.
One of the use cases for which Intents are used a lot is to launch Activities and they can be thought is a data structure that holds an abstract description of an action to be performed
There are 2 components to an Intent:
-
Action: What action has to be performed, some examples of this are:
-
ACTION_VIEW
displays data to the user, for instance, if we use it astel: URI
it will invoke the dialer (weโll see this in our test example), -
ACTION_EDIT
gives explicit edit access to given data
-
-
Data: Data to operate on expressed as a
Uri
You can read the full dochere to understand more about Intents
Understanding our App under test ๐ต๐ป
Letโs start by understanding the app under test
Weโll useIntentsBasicSample
app, which has an EditText
to enter a phone no and a Button
to either call a number or randomly pick a no, if the user taps on the call number button it launches a dialer app
The below scenarios are possible
GIVEN user is on home screen
WHEN user taps on enter phone no EditText with id: @id/edit_text_caller_number
AND user types a valid phone no
AND user taps on call number Button with id: id @id/button_call_number
THEN the dialer activity is shown with entered phone no
Iโve written this in Gherkin syntax for clarity, however in a live test, the tests should always describe behavior and no be as procedural as iโve written below. Read this page on cucumber website to understand more
Letโs use Layout inspector to grab the selectors for the elements we want to work with:
Add required dependencies
We need to add espresso-intents
dependency to our app/build.gradle
file as below, also itโs only compatible with espresso 2.1+
and android testing lib version 0.3+
, so we need to double-check their versions in our dependencies as well
androidTestImplementation 'androidx.test.espresso:espresso-intents:3.4.0'
androidTestImplementation 'androidx.test:runner :1.4.0'
androidTestImplementation 'androidx.test:rules:1.4.0'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'
Test to launch a dialer activity using intents and validation
Below is the complete test to perform our scenario, donโt worry ๐ง๐ปโโ๏ธ if it does not make sense right now, weโll unpack this in detail below, the complete example is mentioned so that you can skim through its structure first before we dive deeper
@RunWith(AndroidJUnit4.class)
@LargeTest
public class DialerActivityPracticeTest {
public static final String VALID_PHONE_NUMBER = "123-456-7898";
@Rule
public GrantPermissionRule grantPermissionRule =
GrantPermissionRule.grant("android.permission.CALL_PHONE");
@Rule
public ActivityScenarioRule<DialerActivity> testRule =
new ActivityScenarioRule<>(DialerActivity.class);
@Before
public void setupIntents() {
// Initializes intents and begins recording intents, must be called before
// triggering any actions that call an intent that we want to verify with validation or stubbing
init();
}
@After
public void teardownIntents() {
// Clears intent state, must be called after each test case
release();
}
/** Test to enter a phone number and make a call and verify an intent is launched */
@Test
public void whenTapOnCallNumber_ThenOutgoingCallIsMade() {
// Type a phone no and close keyboard
Uri phoneNumber = Uri.parse("tel:" + VALID_PHONE_NUMBER);
onView(withId(R.id.edit_text_caller_number)).perform(typeText(VALID_PHONE_NUMBER), closeSoftKeyboard());
// Tap on call number button
onView(withId(R.id.button_call_number)).perform(click());
// Verify an intent is called with action and phone no and package
intended(allOf(hasAction(Intent.ACTION_CALL), hasData(phoneNumber)));
}
}
Setting up intents and permissions
- Just like
Views
, weโll use JUnit rules to set up and tear down our intents before and after each test. Weโll useActivityScenarioRule
for this - Since we want to automate the
DialerActivity
class, weโll pass that as the generic type within<>
@Rule
public ActivityScenarioRule<DialerActivity> testRule =
new ActivityScenarioRule<>(DialerActivity.class);
- โ๏ธHowever just adding the rule is not enough and we need to set up and tear down our intents before and after a test as well
- We use
@Before
and@After
JUnit annotations for this purpose and callinit()
before our test starts to execute andrelease()
after the test has been executed
- We use
Note: If you read other blogs and even theofficial google guide on espresso-intents, they show usage of
IntentsTestRule
for setting up intents, but this has recently been deprecated with suggestion to useActivityScenarioRule
withinit()
andrelease()
. Iโm sure these examples and docs would get updated soon, you can meanwhile refer to this blog ๐. You can seethis committo understand how your test code would look like prior and after this change.
@Before
public void setupIntents() {
// Initializes intents and begins recording intents, must be called before
// triggering any actions that call an intent that we want to verify with validation or stubbing
init();
}
@After
public void teardownIntents() {
// Clears intent state, must be called after each test case
release();
}
- We also want our test to have permission to make a call and thus add below snippet as another JUnit rule to ensure we donโt get any permission errors during our test run
@Rule
public GrantPermissionRule grantPermissionRule = GrantPermissionRule.grant("android.permission.CALL_PHONE");
Writing core test logic
With that taken care of letโs write our test
We store a test number in a static variable
public static final String VALID_PHONE_NUMBER = "123-456-7898";
Weโll type the phone no into our EditText as below and then close the keyboard:
onView(withId(R.id.edit_text_caller_number)).perform(typeText(VALID_PHONE_NUMBER), closeSoftKeyboard());
Weโll then tap the call number button
// Tap on call number button
onView(withId(R.id.button_call_number)).perform(click());
Asserting our intent was fired
Great ๐๐ผ, we want to verify that our Intent was actually invoked and we can achieve that by using intended
method that takes an Intent matcher (either an existing one or one that we define).
Tip: ๐ก You can refer toHamcrest Tutorialunderstand how hamcrest matchers work since we are going to use them heavily with espresso
// Verify an intent is called with action and phone no and package
intended(allOf(hasAction(Intent.ACTION_CALL), hasData(phoneNumber)));
If you notice, we use allOf()
matcher, that checks that the examined object matches all of the specified matchers
We first check that the intent
had the correct action by callinghasAction(Intent.ACTION_CALL)
How do we know which action to assert? ๐ค
We can look into app source inDialerActivity
to understand more details about our intent
If you look at createCallIntentFromNumber
method, you can see we create an intent with action Intent.ACTION_CALL
:
final Intent intentToCall = new Intent(Intent.ACTION_CALL);
Also, we see that we set a phone no as the intents data in:
intentToCall.setData(Uri.parse("tel:" + number));
Here is the full method for reference
private Intent createCallIntentFromNumber() {
final Intent intentToCall = new Intent(Intent.ACTION_CALL);
String number = mCallerNumber.getText().toString();
intentToCall.setData(Uri.parse("tel:" + number));
return intentToCall;
}
We also assert that our intent has the correct phone no set as data by:
Preparing the phone no Uri
earlier
Uri phoneNumber = Uri.parse("tel:" + VALID_PHONE_NUMBER);
and then add the below line in our allOf
matcher
hasData(phoneNumber)
Stubbing intent response
If you run this test, youโll see the Dialer Activity pop up
In the above test, we saw how espresso intents could launch another activity and we can quickly validate them using intended
,
However, If we only care about testing the logic of our app and not so much about a 3rd party apps logic (since we anywayscannot manipulate the UIof external activity, nor control the ActivityResult
returned to the activity we are testing), then espresso allows us to stub intents and returns a mock response as well using intending
Letโs see how we can do this:
We add the below line in our @Before
annotated setup method:
intending(not(isInternal()))
.respondWith(new Instrumentation.ActivityResult(Activity.RESULT_OK, null));
Letโs understand its nuts and bolts:
- We can configure espresso to return a
RESULT_OK
for any intent call by usingisInternal()
intent matcher that checks if an intents package is the same as the target package for the instrumentation test.- Since in this case, we want to stub out all intent calls to other activities we can wrap this with a
not()
so ensure we inverse the result of the matcher
- Since in this case, we want to stub out all intent calls to other activities we can wrap this with a
- We then ask espresso to return a
RESULT_OK
as a stubbed response by usingrespondWith()
and mention the result we want to return:
.respondWith(new Instrumentation.ActivityResult(Activity.RESULT_OK, null));
Here:
-
Activity.RESULT_OK
is theresultCode
and -
null
is the resultData since we donโt want to return anything in the intent response
If we rerun the above test, youโll see that no dialer activity is started since the intent call to external activities is going to be stubbed
Test our own apps intent without making an external activity call a.k.a Stubbing response
Letโs see another example of stubbing using intending
updated functional test flow
GIVEN user is on home screen
WHEN user taps on pick number Button with id: @id/button_pick_contact
THEN we check that an intent call was made
AND we verify intent response from Contacts Activity is stubbed
We can write the below test to achieve this flow:
@RunWith(AndroidJUnit4.class)
@LargeTest
public class DialerActivityPracticeTest {
public static final String VALID_PHONE_NUMBER = "123-456-7898";
@Rule
public GrantPermissionRule grantPermissionRule =
GrantPermissionRule.grant("android.permission.CALL_PHONE");
@Rule
public ActivityScenarioRule<DialerActivity> testRule =
new ActivityScenarioRule<>(DialerActivity.class);
@Before
public void setupIntents() {
// Initializes intents and begins recording intents, must be called before
// triggering any actions that call an intent that we want to verify with validation or stubbing
init();
}
@After
public void teardownIntents() {
// Clears intent state, must be called after each test case
release();
}
@Test
public void whenPickNumber_AndTapOnCallWithStub_ThenStubbedResponseIsReturned() {
// To stub all intents to contacts activity to return a valid phone number
// we use intending() and verify if component has class name ContactsActivity
// then we responding with valid result
intending(hasComponent(hasShortClassName(".ContactsActivity")))
.respondWith(
new Instrumentation.ActivityResult(
Activity.RESULT_OK, ContactsActivity.createResultData(VALID_PHONE_NUMBER)));
onView(withId(R.id.button_pick_contact)).perform(click());
onView(withId(R.id.edit_text_caller_number)).check(matches(withText(VALID_PHONE_NUMBER)));
}
}
In this example, we show that we could also selectively stub out intent calls to a particular activity, e.g. if we wanted all calls to ContactsActivity
to return a code: RESULT_OK
and a valid phone no, we can do so by writing:
intending(hasComponent(hasShortClassName(".ContactsActivity")))
.respondWith(
new Instrumentation.ActivityResult(
Activity.RESULT_OK, ContactsActivity.createResultData(VALID_PHONE_NUMBER)));
Note: If we want to stub calls to all classes in a package we could use:
toPackage
method insideintending
intending(toPackage("com.android.contacts")).respondWith(result);
Here we use hasComponent(hasShortClassName(".ContactsActivity"))
that matches any call to class ContactsActivity
and respond with RESULT_OK
, also we return resultData
as the return value of createResultData
method
If we see impl of createResultData
in ContactsActivity
source code, we see it returns an empty intent with a phone no value
@VisibleForTesting
static Intent createResultData(String phoneNumber) {
final Intent resultData = new Intent();
resultData.putExtra(KEY_PHONE_NUMBER, phoneNumber);
return resultData;
}
We finally tap on the pick number button and verify that the EditText
button has the same no as the one returned by the stubbed intent call
And thatโs how you automate intents with espresso! โ
Resources
- You can find the app and test code for this post on Github:
- Please readespresso-intentsthat talks about how to work with intents on Android developers
- Refer to original source code ontesting-samples
Conclusion
Hopefully, this post gives you an idea of how to work with intents in espresso. Stay tuned for the next post where weโll dive into how to automate and work with idling resources with espresso
As always, Do share this with your friends or colleagues and if you have thoughts or feedback, Iโd be more than happy to chat over on Twitter or comments. Until next time. Happy Testing and learning.
Top comments (0)