Develop Reference

Understanding results of Android Espresso instrumentation test

I've created a simple test using Espresso in Android Studio.
The test runs to completion and gives a success message.
However, I'm testing to see if two Button views are visible or not.
I expect to see that one button is visible and the other is not
The test result does not mention this at all. The goal of this test is to run it via Firebase Test Lab on various virtual and real devices and read the results of the test!
Here is the simple test on Android Studio:
#RunWith(AndroidJUnit4.class)
#LargeTest
public class MyGraphingTest {
#Rule
public ActivityScenarioRule<MainActivity> activityRule
= new ActivityScenarioRule<>(MainActivity.class);
#Test
public void MyTestMethod(){
//some test instructions that will lead me to where the two Button views are...
//more test instructions that will hide one Button view from screen, while the other Button view remains visible.
onView(withId(R.id.recenter)).check(matches(isDisplayed()));
onView(withId(R.id.buttonGraph2)).check(matches(isDisplayed()));
}
}
see the attached picture to see the test results!

All checks "returned" true, so your test is passed. Otherwise, test will fall and you will see the reason of the failure. If you want to see additional information about your checks, you should add some logs mannualy.

However, I'm testing to see if two Button views are visible or not. I expect to see that one button is visible and the other is not
Your test, as you posted it, is looking for both views to be displayed. Keep in mind that visible means View.VISIBILITY == VISIBLE. Displayed means you could actually see it in the current screen. Thus a visible view may not actually be displayed if it's off screen or has a zero width or height.
If you actually want to test visibility, you should use withEffectiveVisibility instead of isDisplayed.
The test result does not mention this at all.
You're testing that both views are displayed and the test passes. What do you expect the test to "mention"? Since your test passed, all the assumptions that are in the test held true and the test result has nothing more to tell you.

Firebase TestLab not waiting typing finish to take screenshot

I'm using Espresso in my Instrumented Tests and Firebase to run them, and it is working just fine. But i think Firebase is screenshoting to early. With Spoon, this exactly behavior also happens.
ScreenShotter.takeScreenshot("main_screen_1", activityRule.activity)
isTextEqualsTo(R.id.toolbarTitle, R.string.add_book)
typeTextOnAEmptyEditText(R.id.titleInputText, title)
typeTextOnAEmptyEditText(R.id.descriptionInputText, description)
ScreenShotter.takeScreenshot("main_screen_2", activityRule.activity)
For above sample, i'm getting this as result:
Looking carefully, you can check that description label is going up, during material ui animation, meaning that Espresso has started clicking/typing.
I simply don't know what is going on here.
EDIT: I think it is a bug. It is impossible do capture screen before and after text typing, and only in text typing (ViewActions.typeText). I don't know yet if it is a bug in TextInputLayout (Material UI) or in the screen capture function.

Ok, just found the reason.
It is a bug in InputTextLayout/TextInputEditText, don't know why or how. Just added a new simple EditText and then worked.
Issue oponed.
Lesson learned: If you want to audit a app flow during a ui test, don't use nothing from Material UI.

How to programatically test UI action/activities without repeating test code?

I am very new to TDD and doing TFD in particular. I have not written any codes yet and I wanted to write a test first before develop everything in conjunction with TDD. I want your insight. It seems I am copy pasting my test code. I have made my 'pseudo' user story for me to practice. I am going to paraphrase as this is an actual personal project so please bear with me.
"User can search for a tag"
I have a UI that allows to add and to search for a tag. I made it a little bit conservative by using minimal design. I have a button which toggles between add/search string. I have a CardView to represent this, that CardView is part of the list (its like Facebook). Now I wanted to test that when the user press the button, the content on that card will change to search mode. I pretty much have an idea on how to do this but copy pasting my test code per each test is kind of bothering me.
Here is my test:
public class TagListActivityTest
{
#Test
public void shouldHaveAddTagCard()
{
// User tapped to expand the card
onView(withId(R.id.edittext_description_minimized))
.perform(click());
// User sees the expanded card
onView(withId(R.id.linearlayout_add_note_maximize))
.check(matches(isDisplayed()));
// User sees the expanded card's quick action buttons
onView(withId(R.id.relativelayout_quick_action_button))
.check(matches(isDisplayed()));
// User clicks the add tag button
onView(withId(R.id.imagebutton_tag))
.perform(click());
// User sees the tag list
onView(withId(R.id.coordinatorlayout_tag_list))
.check(matches(isDisplayed()));
// User sees the add tag card
onView(withId(R.id.cardview_add_tag))
.check(matches(isDisplayed()));
}
#Test
public void shouldToggleToSearch()
{
// I am going to do the exact same thing as shouldHaveAddTagCard
// starting from my parent activity until here...
onView(withId(R.id.edittext_description_minimized))
.perform(click());
onView(withId(R.id.linearlayout_add_note_maximize))
.check(matches(isDisplayed()));
onView(withId(R.id.relativelayout_quick_action_button))
.check(matches(isDisplayed()));
onView(withId(R.id.imagebutton_tag))
.perform(click());
onView(withId(R.id.coordinatorlayout_tag_list))
.check(matches(isDisplayed()));
}
}
The TagListActivity is originating from a parent activity. There is some bunch of things you have to do before you can go through the TagListActivity and I already have written test for it. So when I test TagListActivity I have to go first in application's homescreen and navigate from there as you can see from my test procedure shouldHaveAddTagCard. This is my problem, I have to write that procedure over and over again. So when I wanted to test shouldToggleSearch I have to go from the parent activity and write those tests again until I reached TagListActivity. I think I am doing something wrong.
So my question is:
How can I organize this when there is a known user action procedure.
I have written test per procedure to make sure it does what I wanted
to be.
no. 1 makes me feel there is something wrong in what I am doing. I am testing per action (ie user adds tag, user search tag, user deletes tag). So the pre-procedure
I did before user can add tags is the same as user can search tag and I have
to copy paste those pre-procedure before I can actually test.
Also, it seems that I cannot call a test method from a test method as discussed here. I am thinking of reusing test code but it is not advisable.
Am doing things correctly? Any thoughts?

To be honest your tests look very good if this is your first time doing TDD.
Reducing duplication
You can use the #Before annotation to execute some code before each test. In your case, it might look something like this:
// this method will be executed before each test
#Before
public void clickOnEditTextDescription() {
onView(withId(R.id.edittext_description_minimized))
.perform(click());
// put as much set up code in here as you need
}
Bear in mind that, in general, you should not make any assertions in the #Before method. It is for set up code only.
But is it always a good thing?
#Before methods are great, however, remember that copying and pasting test code is not always a bad thing. It's a different balance to production code. In production code, you want no duplication because any given piece of business logic should only exist in one place. In test code however, each test needs to be completely independent from all the other tests. If got rid of all the duplication in your test code, then it would be very difficult to change the shared code without breaking all your tests. Furthermore, your tests would be harder to read because you would have to keep referring to the shared code.
I recommend that you do some research on DAMP (descriptive and meaningful phrases) vs DRY (don't repeat yourself). DAMP is more relevant for unit tests, and allows you to repeat yourself sometimes. DRY is more relevant for production code. The following answer is great at explaining this:
https://stackoverflow.com/a/11837973/6816469

Updating visual components in android embarcadero c++builder

I need to update several visual components in my app during a timeconsuming function, instead my app seems to hang during this function call, rather than update the visual components on the screen. When the function exit, I see only the last changes to the components.
Is there a simple way to do the updates, or do I need to create a parallel process and have a 'timer' to read the data simultaniously (using semaphores) and present them in the timer call ?
Any suggestions ?

I asked the same question yesterday here. Like mh taqia said you can use Application->ProcessMessages() but you have to be careful with it. For my application, it worked but look at some posts about the function first.

I tried following:
MainForm->Invalidate();
MyControlRoot->Repaint();
MyControlRoot is a control containing somewhat 50-60 different other controls
But MyControlRoot wouldn't repaint with this method. ..
Despite the warnings from you Remy, I tried Application->ProcessMessages();
...works for now...
By the way... I cannot see any warnings in Docwiki on using ProcessMessages... what could I expect?
RG

When testing android UI what's the proper way of waiting for UI to be ready?

The test looks like that (it's ActivityInstrumentationTestCase2):
public void testItShowsThreeRows() {
activity = getActivity();
activity.runOnUiThread(new Runnable() {
public void run() {
AccountsList accountsList = new AccountsList(activity, accounts);
list.show();
}
});
ListView listView = (ListView)activity.findViewById(R.id.list);
assertEquals(3, listView.getChildCount());
}
The code I'm trying to test works. But the test fails because activity.runOnUiThread returns immediately. I can insert Thread.sleep and the test turns green but it looks kinda clumsy to me. Do I have to use some thread synchronization or may be poll for some UI element to be ready?
I tried to annotate it with #UiThreadTest but that doesn't work either. The code in list.show() populates a ListView via custom adapter and getView is called on another thread (not the one test runs on - and I have nothing to do with that, I have no threads or asynctasks, no nothing). The test fails again because it returns before UI is ready to be checked.

Calling waitForIdleSync() is better than sleeping for a fixed time.

You have to do a Thread.sleep. I don't think there's a way around this. I don't see why that's "clunky"; you're doing a test, so you have to wait for the system to show the UI element you want to test.
It seems to me, though, that you're really trying to test AccountsList or list. There's little reason to test ListView or findViewById unless you're paranoid.
You should focus on testing AccountsList and your custom adapter. You shouldn't have to use the UI to do this.

Following documentation, "One of the key parts of Espresso is its ability to synchronize all test actions. Espresso waits until the UI is idle before it moves to the next operation. Likewise, it waits for AsyncTask background operations to complete. In general, this should address the majority of test synchronizations in your application. If you have written UI tests before, you will appreciate this feature - there's no need to add waits or synchronization points to your app!
However, sometimes it is not possible to rely on automatic synchronisation, for instance when your app does background operations via non-standard means (managing threads directly or using custom Services). If you have run into a situation where you cannot rely on Espresso to automatically handle the synchronization for you, you can use idling resources and still rely on Espresso for synchronization."
You can read a full example at the testing codelab, you can also get the source code of the sample in github.