Intro to Android

Testing Considerations

In this section, we'll cover some of the most common types of test cases and best practices to consider when determining your testing strategy.

What To Test

You should focus your unit testing on business logic, basic view validation, and functionality. You can validate certain requirements very well with unit testing (e.g. "when I click this bell image, it whistles" or "all activities have a logo on the screen").

Here are some common examples:

  • Ensure the activity and view elements are not null.
  • Ensure expected fragment and view elements are visible on the screen.
  • Ensure that the proper resources are used for view elements.
  • Ensure items are hidden when expected.
  • Ensure toasts are shown.
  • Ensure that your intent starts the correct thing.

What Not To Test

I don't recommend investing much time in verifying less important styling details and XML attributes. Your user interface is likely to change many times a week, but typically the basic view elements and their behavior remain the same. If you updated a test each time a button had new padding, that would get very tedious indeed!


The app logo is 250dp high with a proportional width, the file name is main_logo.png, it has a 20dp left margin and 12dp right margin, has a content description of "Text", and is centered vertically on every screen.

Returns start diminishing pretty quickly when you verify every possible XML attribute! Your time is best spent on items that are relevant to business objectives. From this example, likely the most bang for your buck will come from testing that the proper image is used and making sure that it appears on all expected screens.

Remember any of the attributes you don't test can be caught by designers, quality assurance, business, product, and/or the engineers. A solid strategy is to sweep the app near deployment with a designer to make sure the app appears as expected on a wide range of devices.

Additional Examples