I have a farm of about 20 android devices to run instrumentation UI tests. I use Espresso. Sometimes different system dialogs appear and lead tests to fail.
E.g. USSD result dialog, dialog of lost internet connection, dialog of request to update OS and etc.
Is there a way to catch any dialog and close the one?
This intent doesn't help.
Intent.ACTION_CLOSE_SYSTEM_DIALOGS
it’s simple to click back button event
onView(isRoot()).perform(ViewActions.pressBack());
Add this to your gradle:
androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.2'
And then do this in your test:
UiDevice mDevice = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());
mDevice.pressBack();
and if you like more in Espresso UI testing, View Expresso Demo Project on GitHub: https://github.com/ranaNarin/Espresso-Android
In this demo project, implemented espresso in all Scenarios:- EditText, Button, options menu click, navigation drawer Open and close, click on recycler view item, open camera and click image using Espresso UI Testing
I've been researching this. The popups have an id and can be dismissed using the test framework. So far I've found how to do it using appium and there is another GitHub that has to this using instrumentation but I haven't implemented this yet.
https://github.com/jamesknowsbest/aws-device-farm-sample-app-for-android
Related
Q. How to capture screenshots while writing the UI test cases in android studio using espresso tool, kotlin language and robolectric test cases using act, arrange and assert
For mobile android application -
1. I am writing the test cases using android studio, kotlin language and robolectric form- act, arrange and assert android UI Test cases.
Running test cases on - emulator, real device
In act- login the app
In arrange - Go to specific screen and perform click function
In assert- validating the UI with specific fields and column text fields and value.
I want to capture the screenshots in between where the assert commands failed or code exit with an error. I was new to kotlin but now learnt how to write the code, need help in how to capture the screenshot in this case.
I had searched helping code on google and try out to find some hint but didn't get much to understand.
Below is the code -
#Test
fun loginSuccess() {
// arrange
// act
onView(withId(R.id.login)).perform(click())
// assert
onView(withId(R.id.logoImg)).check(matches(isDisplayed()))
}
You can refer to this article. There is not a single method which handles everything for you.https://medium.com/#mohitgupta92/custom-failure-handler-for-android-espresso-c8c99eb65a32
I am trying to automate my android application. When I start the test I try to switch environment from the debug drawer. While switching environment the application closed and opens a new instance for that particular environment. The test fails the time the application closes.
Getting this error: Reason: 'Instrumentation run failed due to 'Process crashed.''
IS there any way the script does not fail and wait until the new application opens
You need to use uiautomator along with espresso for this kind of use cases.Use Uiautomator to switch the environment and then let the espresso steps run.
For more details refer-https://developer.android.com/topic/libraries/testing-support-library/index.html#UIAutomator
The UI Automator testing framework provides a set of APIs to build UI tests that perform interactions on user apps and system apps. The UI Automator APIs allows you to perform operations such as opening the Settings menu or the app launcher in a test device. The UI Automator testing framework is well-suited for writing black box-style automated tests, where the test code does not rely on internal implementation details of the target app.
onView(withId(R.id.BUTTON))
.perform(click())
.check(matches(withContentDescription(R.id.my_layout)));
onView(withId(R.id.tp_layout))
.check(matches(isDisplayed()));
I am trying to test whether button click migrates to next screen or not..
how can I match, with this only first test is running and it displays tests failed.
You can use an Espresso extension - Espresso-Intents.
Here is the official tutorial.
Quick quote:
Espresso-Intents is an extension to Espresso, which enables validation
and stubbing of intents sent out by the application under test. It’s
like Mockito, but for Android Intents.
If your app delegates functionality to other apps or the platform, you
can use Espresso-Intents to focus on your own app's logic while
assuming that other apps or the platform will function correctly. With
Espresso-Intents, you can match and validate your outgoing intents or
even provide stub responses in place of actual intent responses.
My android app has a service which sends notifications to user based on parameters like number of runs of the app. The notifications are sent at different times in different situations. I want to test whether notifications are sent at the right times in all the different cases. Does android provide a way of such a testing ?
Testing Notification using UIAutomator:
Just go through the below code. It will help you in testing the notification.
UiDevice device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());
device.openNotification();
device.wait(Until.hasObject(By.text(NOTIFICATION_TITLE)), TIMEOUT);
UiObject2 title = device.findObject(By.text(NOTIFICATION_TITLE));
UiObject2 text = device.findObject(By.text(NOTIFICATION_TEXT));
assertEquals(NOTIFICATION_TITLE, title.getText());
assertEquals(NOTIFICATION_TEXT, text.getText());
title.click();
device.wait(Until.hasObject(By.text(ESPRESSO.getName())), TIMEOUT);
Don't forget to add the UIAutomator dependencies in build.gradle.
// UIAutomator dependency
androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.1'
Please read this article
http://qathread.blogspot.com/2015/05/espresso-uiautomator-perfect-tandem.html
Here is a nice explanation of this topic:
Espresso for Android is perfect and fast test automation framework,
but it has one important limitation - you are allowed to operate only
inside your app under test context.
This means, it is not possible to automate tests for app features such as:
application push notifications
contact synchronization
navigating from another app to your app under test,
Since you have to deal with other apps from the mobile device -
NotificationBar, Contacts or People app, etc.
In fact it wasn't possible until the release of UIAutomator 2.0. As
stated in Android Developers blog post - "...Most importantly, UI
Automator is now based on Android Instrumentation...". And because
of that we can run UIAutomator tests as well as Espresso tests
using Instrumentation test runner.
In addition to that we can combine UIAutomator tests together with
Espresso tests and this gives us the real power and control over the
phone and application under test.
I'd like to use Behavior Driven Development (BDD) to develop an Android app. I'm thinking of using jBehave with Robolectric. Someone wrote about using jBehave with Robotium but does anyone know if Robolectric can be used instead of Robotium with jBehave?
Any known issues?
Robotium is a tool for unit/acceptance testing on emulator or real device, Robolectric is library to unit test android code on desktop jvm. I think it would be possible to pair jBehave with Robolectric but again as for me it would be something that doesn't fit well.
As example simple behaviour test on android:
Activity A with list, user press item at position 2, user see Activity B details
for for the second object in the list.
Test on Robotium will:
press on activity A list item
check that activity B shown with UI that represents details
Tests with Robolectric are smaller:
you could check that pressing item on A will fire Intent for launching new activity with specified details
another test would check that B will show details
So you could try with jBehave map "see item details" to Robolectric “Intent fired” but this check is misleading because there so many things could happen from firing Intent to showing Activity with details.
You could in Robolectric also try to fire activity and check details but this level of mocking is too much for BDD which suppose to have as less mocking as possible.