adevintaspain/barista

:coffee: The one who serves a great Espresso

barista's Issues

Perform scrolls before all actions to avoid issues when changing phones

A test could pass on your phone, and crash in the C.I. emulator because it's smaller than yours. That makes development phase slower. If Barista just tries to scroll to a View before writing into it or doing whatever action, tests will be less Flaky.

It just happened on the InfoJobs app, trying to open a Spinner that was only 90% visible 😢

Rename BaristaSwipeActions to BaristaViewPagerActions

We are relating the Action classes to Android Wigets. "Swipe" is not an Android widget so... let's rename it!

Avoid asking for an ID if there is only one ListView

Create one rule that uses the other Barista ones

Just a way to ease copypasting to newcomers

assertNotDisplayed doesn't work when multiple views matches the text

If any of the matching views are displayed, this assertion should give a green.

Related with #37, but with assertNotDisplayed()

Swipe a ViewPager N times

Right now, if you want to swipe forward a ViewPager 10 times, you have to call swipeViewPagerForward ten times. It could be great if you can delegate this ugly for to Barista.

Create a @Rule to clear all databases

In the same way @Sloy created a Rule to clear all Shared Preferences at #24, we need to do the same with the SQLite databases

Create a rule to delete files

Some apps (like Fotocasa one) save things on the disk. So, to isolate tests, we need to remove it before running the test.

Let's write a lovely Rule that removes the app files before running the test.

PermissionGranter doesn't work on Android 23 or 25

Reproduced with QuitNow! tests on the emulator. PermissionGranter just avoids tapping the accept button.

Check the color of the text of a TextView

Add a way to do an elegant Thread.sleep

https://youtu.be/isihPOY2vS4?t=11m25s

uiController.loopMainThreadForAtLeast(millis)

Change the ViewPager methods to apply only on displayed widgets

In one case, we have a ViewPager inside a ViewPager. Then, the ViewPager that we want to move is repeated over lots of times inside another ViewPager. That makes Espresso to launch a "multiple ViewPagers match that ID". But well, obviously, we want to interact with the ViewPager that is visible.

So:

onView(allOf(ViewMatchers.withId(R.id.the_id), ViewMatchers.isDisplayed())).perform( new ViewAction[] { ViewActions.swipeLeft() });

Check if ImageView is showing an image

This StackOverflow answer could be useful: http://stackoverflow.com/questions/38867613/espresso-testing-that-imageview-contains-a-drawable

Update Barista's icon using the .SVG provided by the lovely designer

Issue when writing in an EditText that appears in another page of a ViewPager

Same than #68 , but writing into EditText. That's strange... looked at the source, and it should work. It's EDD time.

Just for the information, a piece of code to showcase the issue. The click works and the write not:

click(R.id.et_postal_code)
writeToEditText(R.id.et_postal_code, "17750")

Avoid asking for an ID if there is only one ViewPager

If I'm in a screen with only one ViewPager, why do I need to say swipePagerForward(viewId)? I just want to say swipePagerForward(). In addition, it will prevent the test of breaking if someone refactors the layout.xml while using a gradle flavor different than the test one.

Launch version 1.0.0

Wep! Look at the changelog. It has several changes, and one breaking change: #53

assertDisplayed doesn't work when multiple views matches the text

We found a case that I think Barista should handle.
In an Activity we had multiple views with the same text "Banana", and we were doing assertDisplayed("Banana") to verify that the data had been loaded and displayed.

Espresso fails because multiple views match the condition withText().

From the perspective of someone using Barista and reading the method assertDisplayed, I think it should work. What do you guys think???

Check that edit text has hint

onView(withId(R.id.EDIT_TEXT_ID)).check(matches(withHint(R.string.HINT_TEXT)));

Tap a RadioButton using its position, not its ID

Sometimes, we generate the RadioButtons of the RadioGroup programmatically. Then, there's not any way to tap the first RadioButton item if not's using the text :·(

Scroll a Recycler to a position

onView(withId(id).perform(scrollToPosition(position));

Mention the Espresso issues that Barista fixes magically

• Scrolling to a button if needed
• Repeating scrolling if it doesn't performs as expected
• Actions apply only to visible things, so if there's a View with the same ID in another ViewPager, Espresso doesn't crash

Migrate to Kotlin

Well it's obvious, isn't it?

There's too much Java in this project.

Assert that a view is transparent: alpha=0

assertNotDisplayed() fails if the View is Visible with alpha=0 👏

Move internal classes to an internal package

We have many classes in Barista. Visible ones.

I think it would be a good idea to use packages to separate the public API and the internal classes. I've seen this in many libraries.
It means moving all classes intended for internal usage to an internal subpackage.

What do you think @rocboronat?

RecyclerView click actions don't work on wrapped views

The method BaristaRecyclerViewActions.performClick() only works when the itemView of the ViewHolder has the clickListener for the row.
If the clickListener is setted on a children view, the click is not dispatched to it.

For example, when the ItemView contains the clickable row AND a separator/shadow below. Or when using custom Adapters that wrap your view inside another one (like https://github.com/emilsjolander/StickyListHeaders).

The problem seems to be with clickUsingPerformClick() method, which calls performClick() on the specific ItemView, and doesn't let the click pass through its children.

click(id) doesn't work when multiple views in the hierarchy

When I click close_button:

I get error android.support.test.espresso.AmbiguousViewMatcherException: 'with id: com.schibsted.android.rocket.kufar.debug:id/close_button' matches multiple views in the hierarchy. Problem views are marked with '****MATCHES****' below.

Permission Error

@Test
public void validateInputText() {
	PermissionGranter.allowPermissionsIfNeeded(Manifest.permission.WRITE_EXTERNAL_STORAGE);
	onView(withId(R.id.fragment_input_id_number)).perform(typeText(SIMPLE_INT)).check(matches(withText(SIMPLE_INT)));
}

description

I setting app to request permission first the first time running, I saw the dialog is out, But this code didn't click allow, and I cause NoActivityResumedException

Image

Click by R.string.text

Needed by @alorma and his great project at Schibsted 🎉

Run task :library:mavenAndroidJavadocs on PRs

To avoid failures while deploying because of JavaDoc, we should also run the task :library:mavenAndroidJavadocs on PRs. Otherwise it will only run when we try to make a release, and fail miserably.

Accepting multiple permissions at once

As @knezmilos explains at a StackOverflow question, if using multiple permissions at the same time, the indexes get shifted - 0 is nothing (false), 1 is deny and 2 is allow. So, our PermissionGranter doesn't work as expected.

The complete thread, here: http://stackoverflow.com/questions/33929937/android-marshmallow-test-permissions-with-espresso

Also use resource name to find a View

In some projects, we needed to find Views using their res-name:
onView(withResourceName("list")).check(...

Accept text when it's in uppercase, to speed up testing

If R.string.search = "Search" but the screen shows SEARCH for some design decision, having a assertDisplayedIgnoreCase makes things simpler.

@Sloy what do you thing about this? Probably I'm too aggressive making things easy... ?

Scroll to a R.string.text

BaristaScrollActions.scrollTo(R.string.text) doesn't have any implementation

Offer enableCheckBox() and disableCheckBox()

Assert No Duplicate Menu

Hi.

I had a situation today where some menu options were duplicated after refreshing view (tl&dr; using swipe to refresh)

Is there any way to use Barista to check this case? (That view is not duplicate)

Tap a button of an item inside a Recycler

Needed by Fotocasa and some Schibsted's internal libraries.

Pass Espresso tests on some Continous Integration platform

For some reason, the instrumental tests fails on the public Travis. We must fix it to guarantee Barista's confidence.

Avoid asking for an ID if there are only one RecyclerView

Bug autoscrolling until next item at BaristaClickActions.click(id)

This line introduces the issue: it doesn't scroll until the View is visible, cos just matches visible things.
Espresso.onView(DisplayedMatchers.displayedWithId(id)).perform(new ViewAction[]{ViewActions.scrollTo(), ViewActions.click()});

Assertion for EditText errors

We could have an assertion for EditText error field, that handles both the native "setError" and the pretty one from TextInputLayout.

Add the download section in the readme

The library is missing the most important thing:

How to download!
A short copy&paste of gradle's "compile" line in the readme is the difference between success or failure. Doctors said.

Click() method name conflicts with Espresso's click()

When writing tests with the auto-imports enabled, using the click(id) from Barista becomes a bit painful because Espresso has another static click() method, and Android Studio will automatically import the Espresso one first, forcing you to manually remove the import and use the Barista one.

This is an issue I've faced myself, and also I've been told by others (hi @MarinaTov!).

My proposal is to rename the static click(id) methods to something like clickOn(id) so we don't conflict with Espresso.
The old methods should probably be maintained to avoid breaking the public API, but at least deprecate them.

Fix overflow menu item click tests

They were added at #78 , and ignored at CI at #83

@alorma please, can you try to figure what's happening there? @Sloy added some suggestions at #83 . They could be useful...

RadioButtons Actions doesn't scroll if needed

Disable unwanted PR merging options

By default the three merging options are enabled (merge, squash&merge, rebase&merge).
We should always merge PRs the same way, so leaving only the prefered option could avoid mistakes.

We've been using the squash&merge option, so we should disable the other two.

Same Id matches multiple views in the hierarchy

Having a view pager with multiple fragments, we are not able to click on one of the items because they have both the same id.
When trying to get the item by id ViewMatchers.withId(R.id.offer_list_recyclerview) we get the following exception from espresso:
android.support.test.espresso.AmbiguousViewMatcherException:

The solution that we found is:

    sleep(1000);
    Espresso.onView(allOf(ViewMatchers.withId(R.id.offer_list_recyclerview), isDisplayed())).perform(new ViewAction[] {
        RecyclerViewActions.actionOnItemAtPosition(0, PerformClickAction
            .clickUsingPerformClick())
    });

With the isDisplayed() we filter the views to match only the ones that are on the screen, so other fragments doesnt influence.
Since we are doing a swipe just before clicking, we need to wait until the swipe finish so there is only one visibile (thats why we put the sleep)

Enjoy.

Assert view has / not has focus

Make Scroll to work with nested ScrollView

Click on a OverFlow hidden Menu

In order to click on a Menu that is hidden by a Overflow i need to do:

        onView(withClassName(endsWith("OverflowMenuButton"))).perform(ViewActions.click());
        click(R.id.profile_logout_action);

It would be great to have a simple click(R.id.profile_logout_action)or maybe better: clickMenu(R.id.profile_logout_action)