The guy who serves a great Espresso
Barista makes developing UI test faster, easier and more predictable. Built on top of Espresso, it provides a simple an discoverable API, removing most of the boilerplate and verbosity of common Espresso tasks. You and your Android team will write tests with no effort.
Psst, hey. Migrating to Barista 2? Check out this guide to help you with the transition.
Import Barista as a testing dependency:
androidTestImplementation('com.schibsted.spain:barista:2.8.0') {
exclude group: 'com.android.support'
exclude group: 'org.jetbrains.kotlin' // Only if you already use Kotlin in your project
}You might need to include the Google Maven repository, required by Espresso 3:
repositories {
google()
}Barista already includes espresso-core and espresso-contrib. If you need any other Espresso package you can add them yourself.
// Click widgets
clickOn(R.id.button);
clickOn(R.string.button_text);
clickOn("Next");
clickBack();
// Long click widgets
longClickOn(R.id.button);
longClickOn(R.string.button_text);
longClickOn("Next");
// Click menu items, with or without overflow
clickMenu(R.id.menu_item);
// Writing into widgets
writeTo(R.id.edittext, "A great text");
writeToAutoComplete(R.id.autocomplete, "Another great text");
clearText(R.id.edittext)
// Operate on ListViews and RecyclerViews indistinctly by position
clickListItem(R.id.list, 4);
clickListItemChild(R.id.list, 3, R.id.row_button);
scrollListToPosition(R.id.list, 4);
assertListItemCount(R.id.listId, 5)
assertDisplayedAtPosition(R.id.recycler, 0, "text");
assertDisplayedAtPosition(R.id.listId, 0, R.id.text_field, "text");
clickSpinnerItem(R.id.spinner, 1);
// Select items on RadioButtons
clickRadioButtonItem(R.id.radiogroup, R.id.radio_item);
clickRadioButtonItem(R.id.radiogroup, "The radio text");
clickRadioButtonPosition(R.id.radiogroup, 42);
// Pick data on pickers
setDateOnPicker(1986, 03, 23);
setTimeOnPicker(17, 2);
// Interact with dialogs
clickDialogPositiveButton();
clickDialogNeutralButton();
clickDialogNegativeButton();
// Scroll on scrolls and pagers
scrollTo(R.id.far_away_widget);
scrollTo(R.string.text);
scrollTo("A widget with this text");
swipeViewPagerForward();
swipeViewPagerBack();
// Interact with the navigation drawer
openDrawer();
openDrawerWithGravity(Gravity.RIGHT);
closeDrawer();
closeDrawerWithGravity(Gravity.RIGHT);
// Interact with SeekBars
setProgressTo(R.id.seek_bar, 5);
setProgressToMin(R.id.seek_bar);
setProgressToMax(R.id.seek_bar);
// Pull to refresh in SwipeRefreshLayout
refresh(R.id.swipe_refresh);
refresh(); // Id is optional! We'll find it for you :D
// Close or press ime actions on the Keyboard
closeKeyboard()
pressImeActionButton()
// And another tricky feature, but try not to use it
sleep(2000);
sleep(2, SECONDS);// Is this view displayed?
assertDisplayed("Hello world");
assertDisplayed(R.string.hello_world);
assertDisplayed(R.id.button);
assertDisplayed(R.id.button, "Hello world")
// you can also pass custom matchers
assertDisplayed(withTagValue(is("tagName")))
// ...or not?
assertNotDisplayed("Hello world");
assertNotDisplayed(R.string.hello_world);
assertNotDisplayed(R.id.button);
assertNotDisplayed(R.id.button, "Hello world")
// you can also pass custom matchers
assertNotDisplayed(withTagValue(is("tagName")))
// Is this view enabled?
assertEnabled("Hello world");
assertEnabled(R.string.hello_world);
assertEnabled(R.id.button);
// ...or not?
assertDisabled("Hello world");
assertDisabled(R.string.hello_world);
assertDisabled(R.id.button);
// Hope this view doesn't exist!
assertNotExist("Hello world");
assertNotExist(R.string.hello_world);
assertNotExist(R.id.button);
// Is the expected checkbox checked?
assertChecked("Checked checkbox");
assertChecked(R.string.checked_checkbox);
assertChecked(R.id.checked_checkbox);
// ...and the other checkbox unchecked?
assertUnchecked("Unchecked checkbox");
assertUnchecked(R.string.unchecked_checkbox);
assertUnchecked(R.id.unchecked_checkbox);
// Does this view have the focus?
assertFocused(R.id.focused_view)
assertFocused("Button")
// ... or not?
assertNotFocused(R.id.focused_view)
assertNotFocused("Button")
// Is this ImageView showing a drawable?
assertHasAnyDrawable(R.id.image_view);
assertHasDrawable(R.id.image_view, R.drawable.ic_barista);
// ...or not?
assertHasNoDrawable(R.id.image_view);
// Does this View have a background?
assertHasAnyBackground(R.id.view);
assertHasBackground(R.id.view, R.drawable.ic_barista);
// ...or not?
assertHasNoBackground(R.id.view);
// What's the state of the Drawer?
assertDrawerIsOpen();
assertDrawerIsOpenWithGravity(Gravity.RIGHT);
assertDrawerIsClosed();
assertDrawerIsClosedWithGravity(Gravity.RIGHT);
// Check TextInputLayout and EditText's hints
assertHint(R.id.edittext, R.string.hint);
assertHint(R.id.edittext, "Hint");
// Check TextInputLayout and EditText's errors
assertError(R.id.edittext, R.string.error);
assertError(R.id.edittext, "Error message");
// Check if text on screen contains given text
assertContains("text");
assertContains(R.id.textview, "text");
// ...or not?
assertNotContains("text");
assertNotContains(R.id.textview, "text");
// Check text is given color
assertTextColorIs(R.id.someRedText, R.color.red);
assertTextColorIs(R.id.someColorListText, R.color.state_list);
// ...or not?
assertTextColorIsNot(R.id.someRedText, R.color.blue);
assertTextColorIsNot(R.id.someColorListText, R.color.another_state_list);
// Check recyclerView item count against expected item count
assertRecyclerViewItemCount(R.id.recycler, 10);
// And another tricky feature
assertThatBackButtonClosesTheApp();
// Is this ImageView showing a drawable?
assertHasAnyDrawable(R.id.image_view);
assertHasDrawable(R.id.image_view, R.drawable.ic_barista);
// ...or not?
assertHasNoDrawable(R.id.image_view);
// Is this ProgressBar/SeekBar progress?
assertProgress(R.id.seek_bar, 5)
assertProgressIsMin(R.id.seek_bar)
assertProgressIsMax(R.id.seek_bar)
If you have a special case not covered by the given assertions API, we encourage you to assert these special cases with our custom assertions API. It's a convenient way to replace plain Matchers with complex assertions. With Barista, you can match any kind of view by knowing its type and passing its viewId, text, or a Matcher<View>. Once you matched it, you will be able to assert all its properties without adding any complex Matcher to your project.
// Matching a Button by text
assertAny<Button>("Save") {
it.enabled == true
}
// Matching a RadioGroup by id
assertAny<RadioGroup>(R.id.radioGroup) {
it.checkedRadioButtonId == R.id.option1
}
// Matching a Progressbar by a Matcher
assertAny<Progressbar>(withId(R.id.progressBar)) {
it.progress == 42
}
// You can also define the assertion description that will be shown if the assertion fails
assertAny<RadioGroup>(R.id.radioGroup, "selected option is the second one") {
it.checkedRadioButtonId == R.id.option1
}// Creates a Bitmap on a camera provided URI
mockAndroidCamera();The new Marshmallow permissions system requires checking for permissions at runtime. As Espresso can't interact with the system dialog, Barista offers a way to allow permissions when needed.
PermissionGranter.allowPermissionsIfNeeded(Manifest.permission.GET_ACCOUNTS);Barista includes a set of useful test rules to help you:
As tests should be isolated, they need to set the environment before running. Espresso doesn't help achieving it but Barista offers a set of rules to clear the app's data before running each test.
// Clear all app's SharedPreferences
@Rule public ClearPreferencesRule clearPreferencesRule = new ClearPreferencesRule();
// Delete all tables from all the app's SQLite Databases
@Rule public ClearDatabaseRule clearDatabaseRule = new ClearDatabaseRule();
// Delete all files in getFilesDir() and getCacheDir()
@Rule public ClearFilesRule clearFilesRule = new ClearFilesRule();We should try to write deterministic tests, but when everything else fails Barista helps you deal with flaky tests using a specific ActivityTestRule and a couple of annotations that repeat your tests multiple times.
// Use a RuleChain to wrap your ActivityTestRule with a FlakyTestRule
private ActivityTestRule<FlakyActivity> activityRule = new ActivityTestRule<>(FlakyActivity.class);
private FlakyTestRule flakyRule = new FlakyTestRule();
@Rule
public RuleChain chain = RuleChain.outerRule(flakyRule)
.around(activityRule);
// Use @AllowFlaky to let flaky tests pass if they pass any time.
@Test
@AllowFlaky(attempts = 5)
public void some_flaky_test() throws Exception {
// ...
}
// Use @Repeat to avoid flaky tests from passing if any repetition fails.
@Test
@Repeat(times = 5)
public void some_important_test() throws Exception {
// ...
}All previous rules can be added at the same time by just adding the BaristaRule.
@Rule
public BaristaRule<MyActivity> baristaRule = BaristaRule.create(MyActivity.class);
//...
baristaRule.launchActivity();The rule assumes some sane defaults:
- Retry flaky tests: 10 attempts
- Launch activity automatically: false
- Initial touch mode enabled: true
- Clear preferences
- Clear databases
- Clear files
Check this link to know how to use @Rule in Kotlin.
In order to speed up testing, Barista keeps in mind some considerations.
- Scrolls when needed: Interacting with Espresso in a
ScrollViewrequires you to scroll to each view, which sometimes doesn't work the first time. Also trying to scroll outside aScrollViewproduces anException, forcing you to change the test depending on the layout. To keep tests simpler, Barista scrolls automatically before interacting with anyView, and only does it if needed. - Scrolls on all views: Barista scrolls on all scrollable views, including
NestedScrollView. Espresso only handlesScrollViewandHorizontalScrollView, so people need to open questions on StackOverflow like this. Or... just use Barista. - Just interacts with displayed Views: Interacting with
Views inside aViewPagerthrowsAmbiguousViewMatcherException, because the views you interact with will be potentially repeated on different pages. Barista only interacts with displayed widgets, so you can focus on the behavior instead of wasting time on details.
We welcome contributions! If you found a bug or have a feature request, feel free to open an issue to discuss it. Remember that bugs reported with a reproducible test are more likely to be investigated and fixed. You can also submit a Pull Request.
We use our company's IntelliJ code style for the project, which is very similar to the official Kotlin Android code style. When submitting code please make sure you use the proper format. You can install the code style into Android Studio by running the script in ./config/androidstudio/install-codestyle.sh. Then restart Android Studio and pick the "BaristaAndroid" schema in preferences.