Now that we’ve covered the logic side of our view, its time to take a look at UI tests. For the UI tests, we’ll use Espresso. With Espresso, we can verify our UI’s behavior. For example, that certain views are visible and contain the information they should contain at the right times. In Espresso tests, we can simulate certain user behaviors like tapping on buttons, swiping left and right or typing text. We can then check if the view is behaving correctly.

Espresso provides test rules to start Activities which are being tested. However, since we are focusing on custom views, we don’t really want to start the Activity our view is contained in, since that would be overkill. Ideally, we’d like to have the custom view separated to allow us to completely focus on the view itself, without distractions.

To achieve this, you might add a mock build flavor to apps which contain utilities for testing views (and Activities / Fragments). Doing this is pretty simple. Just change your module’s build.gradle and add the flavor.

In this example, the mock flavor will be used to store mock data sources, as well as our test utilities. The prod flavor (production) will contain the “real” implementations. Separating these with flavors offers a big advantage: none of your mocked code will appear in the compiled binary of your production application— it’s a separated environment.

Our view’s data source provides us with the user’s account:

In our production flavor, we’ll prepare the implementation of this interface and inject it into our custom view’s presenter. In our mock flavor, we can implement a mocked version of this which allows us to prepare and change the returned account at runtime.

Now, we still need a way to test our custom view with Espresso. For that, we’ll create a MockActivity in our mock flavor, which we can (just like the data source) manipulate before and during runtime. To display our custom view, we’ll need to be able to either change the used layout resource or to directly inject our view into the Activity before it is created. For this example, we’ll use a layout file.

We’re all set-up, now it’s time to finally test our custom view. We’ll create a class in our androidTest directory, and set-up the ActivityTestRule for our MockActivity .

Our MockActivity relies on us providing a layout resource ID, which will then be used to set the Activity’s content view. In our test, we’ll just wrap our custom view in a layout. The XML file is created in the mock flavor’s resource folder.

Coming back to our AccountViewTest , we’ll now set the MockActivity ’s layout resource ID to our newly created one:

Now, each time we start our Activity with our ActivityTestRule , it’ll inflate our mock XML layout, thus display our custom view. Together with our mocked data source, we’re now able to manipulate the view’s state and test and verify its behavior.

An example of a single Espresso UI test with our MockActivity , a mocked data source and our custom view in a mock-only XML layout file: