Espresso for Android is a lightweight, fast, and customizable Android testing framework, designed to provide concise and reliable automated UI tests. At the end of October 2013, Espresso was open sourced by Google after it was announced at the Google Test Automation Conference. From that moment it has been gaining popularity across Android software and test engineers. Now it is the most popular testing framework for the Android platform because its features and development are driven by Google and the Android Open Source community.
This chapter describes Espresso’s basics—the core components of the Espresso testing framework that are used in test automation to replicate the end user behavior. This includes locating application UI elements on the screen and operating on them.
espresso-core—Contains core and basic view matchers, actions, and assertions.
espresso-contrib—External contributions that contain DatePicker, RecyclerView, and Drawer actions, accessibility checks, and the CountingIdlingResource.
espresso-intents—Extensions to validate and stub intents for hermetic testing.
espresso-idling-resource—Espresso’s mechanism for synchronizing background jobs.
espresso-remote—Location of Espresso’s multi-process functionality.
espresso-web—Contains resources for WebView support.
User Interface Testing: Goals and Approach
As mentioned, this book focuses on writing functional end-to-end UI tests, which is the closest way to replicate end user behavior and catch potential issues before a product goes live. Despite the fact that such tests can be much slower than unit or integration tests, they usually discover issues that were not caught during the unit and integration testing stages.
I would like to emphasize the fact that all the test examples in the book do not contain any conditional logic. Conditional logic in test automation is a bad practice because the same test can be executed in different ways, which eliminates easy ways of bug reproduction, reduces the trust in the tests, and increases the test maintenance effort.
Tests should be written in a simple and plain way, so everyone who looks at them will understand what step led to the issue.
Setting Up the Sample Project
Device—Nexus 5X, Android 8.1.0 (API level 27)
IDE—AndroidStudio 3.2.1
Let’s start setting up our sample project. It is a simple TO-DO application forked from the googlesamples/android-architecture GitHub repository ( https://github.com/googlesamples/android-architecture ) and modified in a way to show you most of the Espresso use cases.
Here is the link to the GitHub page where you can download the source code or check out the project directly in your AndroidStudio IDE— https://github.com/Apress/android-espresso-revealed . The sample application allows us to add, edit, and delete TO-DO tasks. It contains different types of UI elements without functional load but the variety of the components used there allows us to see Espresso in action.
Sample project structure
- 1.
Add an androidTest package inside the application module.
- 2.
Set up the Espresso dependencies in the todoapp/app/build.gradle file inside the application module. Put them in the dependencies{...} section.
- 3.Put the Espresso dependency versions inside the root project todoapp/build.gradle file (see Figure 1-2). This is not mandatory but is good practice in case there’s a multi-module application structure. Later, instead of updating dependency versions in multiple gradle files, we would only need to update them in one place.
Figure 1-2todoapp/build.gradle: keeping dependency versions in one place
In most cases, after dependencies have been added, changed, or deleted, we must synchronize the project in AndroidStudio by clicking on the Gradle Sync icon
. You need an Internet connection to download any changed dependencies.
- 4.
Add a test package inside the todoapp/app/src/androidTest/java directory. Usually the test package will have the same name as the application being tested, but with a .test postfix.
Starting from this moment, you can add your first test class and begin writing tests.
Understanding Android Instrumentation
On Android UI tests, we use the instrumentation mechanism to execute tests. Unlike unit tests, which can run on the JVM directly, instrumented tests run on a real device or emulator. Such tests have access to the Instrumentation API, which enables us to control the test application from our test code, provides access to the context of the application, and allows us to replicate user behavior through different UI actions, like click, swipe, etc. This is achieved because the instrumented test application runs in the same process as the application being tested. Instrumentation will be instantiated before any of the application code, allowing it to monitor the interactions that the system has with the application.
In both cases, we provide the instrumentation test runner name and the target application package, which is the test application package. In the build.gradle file, it is called applicationId. AndroidJUnitRunner is the default Android JUnit test runner, starting from API level 8 (Android 2.2). It allows us to run JUnit3 or JUnit4 based tests.
The test runner handles loading your test package and the test app to a device, running your tests, and reporting the test results.
To access the information about the current test, we run the InstrumentationRegistry class . It holds a reference to the instrumentation object running in the process as well as to the target application context object, the test application context object, and the command-line arguments passed into your test.
Whenever we create a test class, it or its superclass should be annotated with a @RunWith(AndroidJUnit4.class) annotation. Otherwise, the default JUnit runner will take over the running process and the tests will fail.
To execute code once before or after any test method inside the class, the @BeforeClass or @AfterClass JUnit annotations can be used.
To execute code before or after each test method inside the class, the @Before or @After JUnit annotations can be used. This can be useful when several tests need similar objects created or deleted before/after they can run.
The @Rule annotates fields that reference rules or methods that return a rule. Rules can be used for different purposes. For example, later in the book, we will talk about activity or TestWatcher rules.
Espresso Basics
Every mobile application has some form of user interface (UI). In the Android world, this is accomplished through the use of View and ViewGroup objects. They are used for drawing UI elements on the Android device screen. From a testing point of view, we are interested in these UI elements to further perform actions or verifications on them. The first step we have to do is locate these views in the application UI.
Identifying Application UI Elements
- 1.
Search for UI elements on the screen (buttons, lists, edit text fields, icons, etc.).
- 2.
Perform actions on UI elements (click, double-click, swipe, type, etc.).
- 3.
Check the result (text is typed, click led to expected result, list is scrolled, etc.).
So, our first task when we start writing automated tests is to find the UI elements in the application we would like to perform actions on. They can be easily located with the help of a couple of tools. The first possibility is to use Android Device Monitor.
icon (see Figure 1-3). After following these steps, you will be able to inspect the application UI by just clicking on the available elements inside the Android Device Monitor. The details of the element are shown on the right side, including resource ID, text, content description, etc. This information is very important because it will become the base for views identification inside the application UI.
Identifying UI elements by clicking on them
Selecting a running process from the Layout Inspector
Analyzing the application layout from the Layout Inspector
As you can see in Figure 1-5, the Layout Inspector view is more detailed. It provides us with more data compared to the Android Device Monitor, which provides more possibilities for view identification and verification. Another benefit of the Layout Inspector is that it saves the layout dumps inside the /captures folder, which can be easily accessed without the need to start another tool. They can be committed into the source control system and used by multiple team members.
Exercise 1
Inspecting the Application Layout
- 1.
Make the layout dump in the All TO-DOs list and study the hierarchy structure.
- 2.
Open a contextual menu toolbar in the All TO-DOs list and create a layout dump. Study the hierarchy structure.
Espresso
onView() —A ViewInteraction for a given view. Takes the hamcrest ViewMatchers instance(s) as a parameter. You can pass one or more of these to the onView() method to locate a view, based on view properties, within the current view hierarchy.
Note
The view has to be part of the view hierarchy. This may not be the case if it is rendered as part of an AdapterView (e.g., a ListView). If this is the case, use Espresso.onData to load the view first.
onData() —A DataInteraction for a data object (e.g., a ListView). Takes as a parameter a hamcrest matcher that matches the data object represented by the single item in the list.
pressBack() —A press on the back button. Throws PerformException if the currently displayed activity is a root activity, since pressing the back button would result in the application closing.
closeSoftKeyboard() —Closes the soft keyboard if it’s open.
openContextualActionModeOverflowMenu() —Opens the overflow menu displayed in the contextual options of an ActionMode.
openActionBarOverflowOrOptionsMenu() —Opens the overflow menu displayed within an ActionBar.
We will start with the basic Espresso functionality. First we will see how operations on single views work with the onView() method. As a parameter, it takes a hamcrest matcher to match a view in the application UI. We will learn more about view matchers in the next section.
Espresso ViewMatchers
isAssignableFrom() —Matches a view based on an instance or subclass of the provided class. Normally used in combination with other ViewMatchers. Commonly used.
withClassName() ⎯Returns a matcher that matches views with class name matching the given matcher.
isDisplayed() ⎯Returns a matcher that matches views that are currently displayed on the screen to the user. Commonly used.
Note
isDisplayed() will select views that are partially displayed (e.g., the full height/width of the view is greater than the height/width of the visible rectangle). If you want to ensure the entire rectangle is displayed, use isCompletelyDisplayed().
isCompletelyDisplayed() ⎯Returns a matcher that only accepts a view whose height and width fit perfectly within the currently displayed region of this view.
Note
There exist views (such as ScrollViews) whose height and width are larger than the physical device screen by design. Such views will never be completely displayed.
isDisplayingAtLeast() ⎯Returns a matcher that accepts a view so long as a given percentage of that view’s area is not obscured by any parent view and is thus visible to the user.
isEnabled() ⎯Returns a matcher that matches view(s) that are enabled. Commonly used.
isFocusable() ⎯Returns a matcher that matches view(s) that are focusable.
hasFocus() ⎯Returns a matcher that matches view(s) that currently have focus.
isSelected() ⎯Returns a matcher that matches view(s) that are selected.
hasSibling() ⎯Returns a matcher that matches view(s) based on their siblings. This may be particularly useful when a view cannot be uniquely selected on properties such as text or view ID. For example, a call button is repeated several times in a contact layout and the only way to differentiate the call button view is by what appears next to it (e.g., the unique name of the contact).
withContentDescription() ⎯Returns a matcher that matches view(s) based on the content description property value. Commonly used.
withId() ⎯Returns a matcher that matches view(s) based on content description’s id. Commonly used.
Note
Android resource IDs are not guaranteed to be unique. You may have to pair this matcher with another one to guarantee a unique view selection.
withResourceName() ⎯Returns a matcher that matches view(s) based on resource ID names, (for instance, channel_avatar).
withTagKey() ⎯Returns a matcher that matches view(s) based on tag keys.
withTagValue() ⎯Returns a matcher that matches view(s) based on tag property values.
withText() ⎯Returns a matcher that matches view(s) based on its text property value.
withHint() ⎯Returns a matcher that matches view(s) based on its hint property value.
isChecked() ⎯Returns a matcher that accepts it only if the view is a CompoundButton (or a subtype of) and is in checked state. Commonly used.
isNotChecked() ⎯Returns a matcher that accepts it only if the view is a CompoundButton (or subtype of) and is not in the checked state. Commonly used.
hasContentDescription() ⎯Returns a matcher that matches view(s) with any content description.
hasDescendant() ⎯Returns a matcher that matches view(s) based on the presence of a descendant in its view hierarchy.
isClickable() ⎯Returns a matcher that matches view(s) that are clickable.
isDescendantOfA() ⎯Returns a matcher that matches view(s) based on the given ancestor type.
withEffectiveVisibility() ⎯Returns a matcher that matches view(s) that have “effective” visibility set to the given value.
withAlpha() ⎯Matches view(s) with the specified alpha value. Alpha is a view property value from 0 to 1, where 0 means the view is completely transparent and 1 means the view is completely opaque.
withParent() ⎯A matcher that accepts a view only if the view’s parent is accepted by the provided matcher.
withChild() ⎯Matches view(s) whose child is accepted by the provided matcher.
hasChildCount() ⎯Matches a ViewGroup (e.g., a ListView) if it has exactly the specified number of children.
hasMinimumChildCount() ⎯Matches a ViewGroup (e.g., a ListView) if it has at least the specified number of children.
isRoot() ⎯Returns a matcher that matches the root view.
hasImeAction() ⎯Returns a matcher that matches views that support input methods.
hasLinks() ⎯Returns a matcher that matches TextView(s) that have links.
withSpinnerText() ⎯Returns a matcher that matches a descendant of a spinner that is displaying the string of the selected item associated with the given resource ID.
isJavascriptEnabled() ⎯Returns a matcher that matches web view(s) if they are evaluating JavaScript.
hasErrorText() ⎯Returns a matcher that matches EditText based on the edit text error string value.
withInputType() ⎯Returns a matcher that matches android.text.InputType.
withParentIndex() ⎯Returns a matcher that matches the child index inside the ViewParent.
User properties
UI properties
Object matchers
Hierarchy
Input
Class
Root matchers
Espresso cheat sheet 2.1⎯ViewMatchers (source https://developer.android.com/training/testing/espresso/cheat-sheet )
Let’s look at some examples of how these ViewMatchers can be used with our sample application. Open the ViewMatchersExampleTest.java class and look at the test methods. All of them are listed in Figure 1-7.
List of TO-DOs in the TO-DO application
EditText example from the General preferences in the application settings
General preferences section in the application settings
The TO-DO task detail view
We will not discuss the cursor matchers shown in the ViewMatchers section of the Espresso spreadsheet, because their goal is to operate at a database level, which is used in unit and integration tests and is therefore out of this book’s scope.
To get a full overview of the hamcrest matchers, refer to their official documentation at http://hamcrest.org/JavaHamcrest .
So, now we have an understanding of ViewMatchers. We also understand that they play one of the most important roles in the Espresso testing framework. Their task is to locate the matched view inside the application layout or fail if the match did not happen.
Espresso’s ViewInteraction Class
In the previous examples, we were doing new perform() and check() operations on the views. These methods are representatives of the ViewInteraction class . Interactions act like glue between the ViewMatcher and the ViewAssertion or ViewAction.
perform()⎯Receives a view action or a set of view actions as a parameter and performs them on the view selected by the current ViewMatcher.
check()⎯Receives a view action or a set of view actions as a parameter and checks it on the the view selected by the current ViewMatcher.
inRoot()⎯Receives a root matcher as a parameter and sets the scope of the view interaction to the root view, identified by the root matcher.
Note
Espresso performs all the actions on the UI thread, which means that it will first wait for the application UI to render and only after that perform the required steps. This ensures that the application UI elements are fully loaded and displayed on the screen, which increases test reliability and robustness. It will also eliminate the need of having waits and sleeps in the tests.
In the following section, you will see examples of how perform() and check() view interactions can be used.
Espresso’s ViewActions Class
clearText() ⎯Returns an action that clears text on the view. The view must be displayed on the screen.
click()⎯Returns an action that clicks the view. At least 90% of the view must be displayed on the screen.
swipeLeft() ⎯Returns an action that performs a swipe right-to-left across the vertical center of the view. The swipe doesn’t start at the very edge of the view, but is a bit offset, since swiping from the exact edge may cause unexpected behavior (e.g., it may open a navigation drawer). Other swipe actions defined by Espresso are swipeRight(), swipeDown(), and swipeUp(). For all the swipe actions, at least 90% of the views must be displayed onscreen.
closeSoftKeyboard() ⎯Returns an action that closes the soft keyboard. If the keyboard is already closed, it is non-operational.
pressImeActionButton() ⎯Returns an action that presses the current action button (Next, Done, Search, etc.) on the IME (Input Method Editor).
pressBack() ⎯Returns an action that clicks the hardware back button.
pressMenuKey() ⎯Returns an action that presses the hardware menu key. Most modern devices on the market no longer support the hardware menu key, so this method is rarely used.
pressKey() ⎯Returns an action that presses the key specified by the key code (e.g., KeyEvent.KEYCODE_BACK). There is a huge list of all possible key codes declared in the andrid.view.KeyEvent.java class.
doubleClick() ⎯Similar to the click() action, this returns an action that double-clicks the view. At least 90% of the view must be displayed onscreen.
longClick() ⎯Returns an action that long-clicks the view. At least 90% of the view must be displayed onscreen.
scrollTo()⎯Returns an action that scrolls to the view. Based on the current implementation, the view we would like to scroll to must be a descendant of one of the following classes: ScrollView.class, HorizontalScrollView.class, ListView.class. At least 90% of the view must be displayed onscreen.
Note
The scrollTo() action will have no effect if the view is already displayed.
typeText()⎯Returns an action that selects the view (by clicking on it) and types the provided string into the view. Appending an ' ' to the end of the string translates to a Enter key event. The view must be displayed onscreen and must support input methods.
Note
The typeText() method performs a tap on the view before typing to force the view into focus. If the view already contains text, this tap may place the cursor at an arbitrary position within the text.
replaceText() ⎯Returns an action that updates the text attribute of a view.
openLink() ⎯Returns an action that opens a link matching the given link text and URI matchers. The action is performed by invoking the link’s onClick method (as opposed to actually issuing a click on the screen).
Espresso cheat sheet 2.1—ViewActions (source https://developer.android.com/training/testing/espresso/cheat-sheet )
Click/Press actions
Gestures
Text-related actions
Conditional actions
These types of actions are represented by one method at this time— repeatedlyUntil() . It enables performing a given action on a view until it reaches the desired state matched by the given ViewMatcher. This action is useful when you’re performing the action repeatedly on a view and then it changes its state at runtime. A good use case to automate with this view action is going through the walkthrough or on-boarding screens from the beginning until the end.
Drag and drop actions
Multi-gesture actions like pinch to zoom
Add a new TO-DO that provides the title and description. Verify it is shown in the TO-DO list.
Add a new TO-DO, mark it completed, and verify it is in the list of completed TO-DOs.
Add a new TO-DO, edit it, and verify the changes.
Note that we introduced the TestData class to keep all the methods that generate input data. This helps reduce the test method boilerplate code. You may notice that we add a unique timestamp in milliseconds to each TO-DO item title and description. This keeps our test data unique, which simplifies a lot of view identification and validation inside the application layout.
Notice how the Espresso notation is flexible—allOf() matcher can be used both inside the onView() method and inside the check(matches()) view interaction.
Exercise 2
Writing Your First Espresso Test Cases
- 1.
Add a TO-DO and mark it as completed. Verify that the checkbox of the completed TO-DO is checked.
- 2.
Add a new TO-DO, open the TO-DO details by clicking on it (hint: use withText() matcher), and delete it by clicking the Delete Task button. Verify the the All TO-DOs list is empty (i.e., verify that the text “You have no TO-DOs!” and that the ID R.id.noTasksIcon are displayed onscreen).
Espresso’s DataInteraction Class
As mentioned in the “Understanding Android Instrumentation” section, the Android application represents its elements via the View or ViewGroup. Single UI elements are drawn inside the View. The ViewGroup is used to represent a set of views or another view group. Think about ViewGroup as a container of UI elements. To represent a list of objects in Android, you can use a class called AdapterView, which extends the ViewGroup class and whose child views are determined by the Adapter. Another possibility to represent a list of objects is to use the RecyclerView, but we discuss it in later chapters.
ListView visualization (source https://developer.android.com/guide/topics/ui/layout/listview )
atPosition(Integer atPosition)⎯Selects the view that matches the nth position on the adapter based on the data matcher.
inAdapterView(Matcher<View> adapterMatcher)⎯Points to a specific adapter view on the screen to operate on. Should be used when we have two or more AdapterViews in one layout. An example may be the layout with a list view and a menu drawer list view.
inRoot(Matcher<Root> rootMatcher)⎯Causes the data interaction to work within the root window specified by the given root matcher. May be useful when we have an AutoComplete list view popping up over the application window.
onChildView(Matcher<View> childMatcher)⎯Redirects perform and check actions to the view inside the adapter item returned by Adapter.getView().
Now, let’s see how DataInteraction methods are used in a test case written for one of the setting functionalities. The Settings application was implemented using the Android Preference component—the UI building block displayed by a PreferenceActivity in the form of a ListView. This class provides the view to be displayed in the activity and associates with a SharedPreferences to store/retrieve the preference data. When specifying a preference hierarchy in XML, each element can point to a subclass of Preference, similar to the view hierarchy and layouts. This class contains a key that will be used as the key into the SharedPreferences.
The dataInteraction() test case flow, starting from the Settings section
Open the DataInteractionsTest class to see the code examples.
Espresso cheat sheet—DataInteraction (source https://developer.android.com/training/testing/espresso/cheat-sheet )
Exercise 3
Writing a Test Case that Operates on a ListView
- 1.
Write a test case that navigates to the Notifications Settings section and clicks the Enable Notifications toggle by text or by ID. Use the Layout Inspector tool to analyze the Notifications Section layout
- 2.
Expand the case from Step 1 and verify that after Enable Notification toggle is switched on, the other notification settings are displayed on the screen.
Operating on RecyclerView Using Espresso
RecyclerView is one of the most commonly used views in Android development. It is a more advanced version of the ListView. Whether your application is an image gallery, a news app, or a messenger, a RecyclerView is usually the best tool to implement it. That is why understanding how to properly write automated tests for this component is so important.
Similar to the simple view, Espresso has a RecyclerViewActions class that contains all the actions you can perform on a RecyclerView, but unfortunately Espresso doesn’t provide RecyclerView matchers. For now, we will look at the RecyclerViewActions examples and in Chapter 2 you will see how to create your own RecyclerView matchers.
We will again refer to our sample TO-DO application, where a list of TO-DOs is represented by a RecyclerView component.
RecyclerViewActions
actionOnItem(final Matcher<View> itemViewMatcher, final ViewAction viewAction)⎯Returns a ViewAction that scrolls a RecyclerView to the view matched by viewHolderMatcher.
actionOnHolderItem(final Matcher<VH> viewHolderMatcher, final ViewAction viewAction)⎯Performs a ViewAction on a view matched by viewHolderMatcher. First it scrolls a RecyclerView to the view matched by itemViewMatcher and then performs an action on the matched view.
actionOnItemAtPosition(final int position, final ViewAction viewAction)⎯First it scrolls a RecyclerView to the view matched by itemViewMatcher and then performs an action on the view at position.
scrollToHolder(final Matcher<VH> viewHolderMatcher)⎯Returns a ViewAction that scrolls a RecyclerView to the view matched by viewHolderMatcher.
scrollTo(final Matcher<View> itemViewMatcher)⎯ViewAction that scrolls a RecyclerView to the view matched by itemViewMatcher.
scrollToPosition(final int position)⎯ViewAction that scrolls a RecyclerView to a given position. The view we operate on must be assignable from a RecyclerView class and should be displayed on the screen.
You can omit for now the generateToDos() method and methods that take view holder matchers as parameters (like scrollToHolder() and actionOnHolderItem() ). They will be discussed in Chapter 2. These tests add 12 TO-DOs, so that some of them are not visible on the device screen. The important information here is that RecyclerView adapter knows about all the 12 TO-DO items, but ViewActions can be performed only on items that are displayed to the user. Here, the scrollToPosition() view holder ViewAction helps us do the scrolling and make the needed TO-DO item visible on the screen. Then, the view action can be performed without issues.
The chained test case required only one change—the ViewActions.pressBack() method was used instead of Espresso.pressBack() .
Exercise 4
- 1.
Based on the examples here, experiment with actions in a RecyclerView. Try to perform actions on the non-visible TO-DO items without scrolling to them and observe the results.
Running Espresso Tests from AndroidStudio
At this moment, we have a basic understanding on how to write automated tests with Espresso. Let’s see how our Espresso tests can be run. This is achievable in two ways⎯via AndroidStudio or from the command line.
Before jumping into running tests, we should understand the concept of the Gradle BuildVariant in AndroidStudio. The BuildVariant represents the process that converts the project into an Android Application Package (APK). The Android build process is very flexible and enables you to create a custom build configuration without modifying the application source code. The flexibility is achieved by BuildVariants, which are the the combined product of build type and product flavor.
Build types define certain properties that Gradle uses when building and packaging your application and are typically configured for different stages of your development lifecycle. For example, the debug build type enables debug options and signs the APK with the debug key, while the release build type may shrink, obfuscate, and sign your APK with a release key for distribution.
The product flavor represents different versions of your app that you may release to users, such as free and paid versions of your app. You can customize product flavors to use different code and resources, while sharing and reusing the parts that are common to all versions of your app.
Android build process (source https://developer.android.com/studio/build )
Select a BuildVariant in AndroidStudio
Creating an instrumentation test configuration
Creating an instrumentation test run configuration
When these steps are done, we are ready to run the selected test. We do so by clicking the arrow 
button in the AndroidStudio toolbar.
Running Espresso Tests from the Terminal
Running Instrumentation tests using shell commands
Running Instrumentation tests using Gradle commands
Running Instrumentation Tests Using Shell Commands
The following shell command can be used to run tests located in the app module.
If you want to run tests from specific test classes, you would add the -e class <Class> parameter to the previous command.
In order to run specific test methods or functions, the class parameter can be extended with the #<testMethod> value, as shown next.
If you want to run tests configured to use the Android Test Orchestrator, the following shell command should be used.
Running Instrumentation Tests Using Gradle Commands
Similar to the shell commands, the class parameter in Gradle can be extended with the #<testMethod> value.
Exercise 5
- 1.
Create a test run configuration for a test method, a test class, and a package. Run the tests.
- 2.
Edit one of the configurations by navigating to the AndroidStudio menu Run ➤ Edit Configurations.... Remove one of the configurations.
- 3.
Practice running a test class or a specific test method using the shell terminal commands.
- 4.
Practice running a test class or a specific test method using the gradle terminal commands.
Summary
In this first chapter, you learned all about the Espresso basics, starting from the dependencies declaration to writing a simple test, which will be the foundation for more advanced examples described later in this book. In addition to that, you received information about how the application layout should be inspected using the Monitor and Layout Inspector tools, how the build process looks, and how Espresso tests are configured and run from the AndroidStudio IDE.