Dunno why espresso intermittently can't find a clearly visible elements.
It fails with:
failed: android.support.test.espresso.NoMatchingViewException: No views in hierarchy found matching: with id: com.justyoyo.staging.debug:id/content_loading_progress_bar
It's freaking frustrating as it doesn't matter whether I'm running the tests on local physical devices, AWS device farm or on Genymotion's emulators. It also doesn't matter that I add an explicit wait SystemClock.sleep(5000); before checking if the element is visible.
I works fine 2,3 times in a row, then it fails.
To give you more insights, we're using Dagger, Mortar and we're running the tests on the UI thread, as running them on separate one was even worse.
I've been having similar issues a lot. I've followed these steps and it has helped a little.
When your test fails with a NoMatchingViewException check the output of the view hierarchy and see if you see the id/text you were searching for. If you find it the view might not be fully visible and you need to scroll to the right position / generally make sure it isn't covered. Even notifications popping down from your status bar can block your view and ruin you test.
If you do not find the view in the view hierarchy try to figure out what layout espresso is actually looking at. I sometimes have dialogs popping up and espresso evaluating that layout instead of the activity that lies below.
Place a breakpoint where your view gets inflated and make sure you actually get there.
But generally difficult to troubleshoot...
Espresso is starting your Activity but is not able to find any view with the id content_loading_progress_bar. This problem does not come from Espresso but from your test.
Make sure your are correctly starting the correct activity. Also regarding to the AWS Device Farm and your tests with Espresso, I suggest you to follow this template. But be careful, to make it work on AWS Device Farm, all your test methods have to start with "testXYZ()" or the farm will not detect them.
Related
I'm working on testing an android app for the Vuzix Blade AR glasses. Vuzix has a library for apps on their devices called HUD-actionmenu which automatically turns a standard dropdown menu into a horizontally scrolling "action menu". I'm writing tests in Espresso, but I'm running into an issue where my tests can only see views that exist within the action menu. If I look for a view, either by id or by text, or any other attribute, I get an error that that view isn't found within the action's hierarchy. The strange thing is that the hierarchy diagram displayed in the error shows ActionMenuBar as the top layer, and only includes views inside the action menu. None of the other views that appear on the screen are exist within the displayed hierarchy, even though they're visible and working fine when running the actual app.
I didn't develop the app, I'm only responsible for the testing, so I may be overlooking something obvious. I'm relatively new to my role as a test engineer, and I've been learning Kotlin and Android development as a whole from scratch for this project. What I have figured out is that each activity class in this app extends ActionMenuActivity, from the Vuzix library, instead of AppCompatActivity. ActionMenuActivity itself extends DynamicThemeActivity (also a Vuzix component), which in turn extends AppCompatActivity. It seems like something is happening in there that is limiting the visible hierarchy of MainActivity (for example) to just the hierarchy of the action menu, but allowing the rest of the views the function as expected. I'm sure Vuzix Blades aren't the most common platform for app development, but I'm wondering if anyone has encountered something similar or has any ideas how I can get around this issue and run tests against all the views in the app, not just the ones inside the action menu.
Hi everyone I have a problem and I don't know how to solve it.
For reference I have root privileges on my device.
It's a question related to domain of pentesting I suppose. But basically there's an app and I know how it's layout is structured from using UIAutomator. I want to scrape the live data that it presents in a list, mainly the TextView elements. After scraping these I want to programatically determine which element to click (hence trying UIAutomator to for clicking).
Unfortunately UIAutomator was too slow and not good for me. I have root so I figure something similar should be possible but I have no clue on where to start.
Basically I want to scrape data and perform UI scrolling, clicking and swiping programatically like Robot class in java.
Read TextViews contained inside a ViewGroup for the apps Activity
Click on one if a certain condition is met
Perform automatic scrolling if necessary
Perform clicks and swipes
I've read that Xposed can be used to read info by hooking provided you have access to the apps code but I do not. I have also tried to decompile the APK to find the methods at that Activity but didn't get anywhere.
Any advice?
Edit: I have already tried examining the API using Burp Suite. While this is also a solution and it works, I would rather have the alternative.
Ever since I started using one of the newer devices from Google for testing, my tests have gotten stuck whenever we call waitForIdleSync(). When going over the documentation for espresso for another reason, I found this amazing tidbit: "To avoid flakiness, we highly recommend that you turn off system animations". See the main page and how to do it programmatically.
However, I've followed the instructions (disable animations and restart my device) and my tests are still getting stuck. Google's documentation has a habit of getting stale fast, so, is there something else I need to do to get this working on newer devices?
I have the same issue and it broke our tests completely for the last two days.
Problem
I researched this issue a lot. In fact it is an AOSP bug: https://code.google.com/p/android/issues/detail?id=82046
(re-opened from this https://code.google.com/p/android/issues/detail?id=61111)
The problem occurs when you have a a animation, loading spinner, progressbar etc. in your Activity/ Layout that runs for a long time.
waitForIdleSync() will therefore wait forever.
In our case it is very problematic, because the methods getActivity(),launchActivity() and launchActivityWithIntent() of ActivityInstrumentationTestCase2and also the new AndroidTestCase have waitForIdleSync() inside.
Solution Suggestions
You can try turning the animations off or set the Visibility of any ProgressSpinner to GONE via an Intent Flag and start it with that. (Personally, I don't like that solution as it would affect the Activity itself and not the Testcode)
Another way would be to mock the preconditions for the Activity to let it not fall into this state.
Other suggestions are welcome!
I have been using Robotium for the last couple weeks writing test cases for an app. It's a great tool but there is one thing that I cannot seem to get working. The app I'm using creates a pop-up window regardless if you are in the app or not to notify the user and when looking at the UI Automator Viewer is is still tied to the same package that I am testing.
The issue is that I cannot read any text or click on anything in the window through Robotium. I created a test to see if Robotium can even see it going through all of the views in debug mode by hand but it seems to be transparent to it. Does anyone know a way around this or another program that would be ideal for this?
I am new to android technology, while developing application i need to debug the UI component like why this textview is not displayed or so.
Like we have Log facility for the java code, do we have similar kind of thing for xml also.
so that we can verify which layout is overlapping with another or find out other distortion in UI
Thanks for your time.
In Eclipse, there is a helpful tool to see your UI hierarchy. When in debug mode, open the "Devices" window (if you can't find it: Alt+Shift+Q, Q). Then click the "Dump View Hierarchy for UI Automator".
You can see some view attributes there as well as the way it's build up.
There's also a hierarchy viewer in the SDK tools/ directory, but I haven't used it yet.
It does have one. A very basic one. The problem is, the 'debugger' doesn't know what you want. Your TextView doesn't display is a problem for you because you want it to display. But the debugger though you left the code like this simply because you will programmatically add the text during run time. So debugger for UI wouldn't solve these kind of problems , but it will give you tips and warnings like this :