[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Automate UI tests\n\nTesting user interactions helps ensure users don't encounter unexpected results\nor have a poor experience when interacting with your app. You should get into\nthe habit of creating user interface (UI) tests if you need to verify that the\nUI of your app is functioning correctly.\n\nOne approach to UI testing is to have a human tester perform a set of user\noperations on the target app and verify that it is behaving correctly. However,\nthis manual approach can be time-consuming and error-prone. A more efficient\napproach is to write your UI tests such that user actions are performed in an\nautomated way. The automated approach lets you run your tests quickly and\nreliably in a repeatable manner.\n\nUI tests launch an app (or part of it), then simulate user interactions, and\nfinally check that the app reacted appropriately. They are integration tests\nthat can range from verifying the behavior of a small component to a large\nnavigation test that traverses a whole user flow. They are useful to check for\nregressions and to verify compatibility with different API levels and physical\ndevices.\n\nRun UI tests\n------------\n\n- To run [instrumented](/training/testing/instrumented-tests) UI tests using Android Studio, you implement your test code in a separate Android test folder - `src/androidTest/java`. The [Android Gradle Plugin](/studio/releases/gradle-plugin) builds a test app based on your test code, then loads the test app on the same device as the target app. In your test code, you can use UI testing frameworks to simulate user interactions on the target app, in order to perform testing tasks that cover specific usage scenarios.\n- You can also use [Robolectric](/training/testing/local-tests/robolectric#ui-testing) to run UI tests on the JVM.\n\nArchitecture and test setup\n---------------------------\n\nThe architecture of your app should let tests replace parts of it for [testing\ndoubles](/training/testing/fundamentals/test-doubles) and you should use libraries that provide utilities to help with\ntesting. For example, you can replace a data repository module with an in-memory\nversion of it that provides fake, deterministic data to the test.\n\n\u003cbr /\u003e\n\n**Figure 3**: Testing a UI by replacing its dependencies with fakes.\n\n\u003cbr /\u003e\n\nThe recommended approach to replace dependencies is dependency injection. You\ncan create your own system [manually](/training/dependency-injection/manual) but we recommend using a DI framework\nlike [Hilt](/training/dependency-injection/hilt-android) for this.\n\nWhy test UIs automatically?\n---------------------------\n\nAn Android app can target thousands of different devices across many API levels\nand form factors, and the high level of customization that the OS brings to the\nuser means your app could be rendered incorrectly or even crash on some devices.\n\nUI testing lets you do *compatibility testing*, verifying the behavior of an app\nin different contexts. You might want to run your UI tests on devices that vary\nin the following ways:\n\n- **API level**: 21, 25, and 30.\n- **Locale**: English, Arabic, and Chinese.\n- **Orientation**: Portrait, landscape.\n\nMoreover, apps should check the behavior beyond phones. You should test on\ntablets, foldables, and other devices. Read more about [testing different screen\nsizes](/training/testing/different-screens).\n\nTypes of UI Tests\n-----------------\n\nThis section covers two types of UI tests:\n\n- [Behavior tests](/training/testing/ui-tests/behavior) analyze the UI hierarchy to make assertions on the properties of the UI elements.\n- [Screenshot tests](/training/testing/ui-tests/screenshot) take screenshots of a UI and compares them with a previously-approved images."]]