[null,null,["最終更新日 2025-08-21 UTC。"],[],[],null,["# Test different screen and window sizes\n\nTesting is an integral part of the app development process. You usually run apps\non an emulator or device to manually verify that your code works as expected.\nHowever, manual testing is time consuming, susceptible to errors, and often\nunmanageable for apps that run on screens and devices of various sizes. The\nproblems of manual testing are most often the result of using a single device\nfor development. As a result, errors can go unnoticed on other devices with\ndifferent form factors.\n\nTo identify regressions on different window and screen sizes, implement\nautomated tests to verify that the behavior and look of your app is consistent\nacross different form factors. Automated tests identify issues early on,\nmitigating the risk of problems impacting the user experience.\n\nWhat to test\n------------\n\nWhen developing UIs made for different screen and window sizes, pay special\nattention to two aspects:\n\n1. How the visual attributes of the components and layouts are different on windows of different sizes\n2. How state is preserved across [configuration changes](/guide/topics/resources/runtime-changes)\n\n### Visual attributes\n\nWhether you customize UIs for different window sizes or not, you should verify\nthat the UIs are displayed correctly. Take into account widths and heights that\nare compact, medium, and extended. See [Window size classes](/develop/ui/compose/layouts/adaptive/window-size-classes) for the\nrecommended breakpoints.\n**Figure 1.** The \"For you\" screen in Now In Android in different window sizes\n\nAlso, your app might not render some components in your design system as\nexpected when their size constraints are stretched.\n\nIf your app has adaptive layouts for different window sizes, you should have\nautomated tests to prevent regressions. For example, fixing a margin on a phone\ncan lead to layout inconsistencies on a tablet. Create [UI tests](/training/testing/ui-tests) to verify\nthe behavior of your layouts and components, or construct screenshot tests to\nverify the layouts visually.\n\n### State restoration\n\nApps running on devices such as tablets are rotated and resized much more\nfrequently than apps on phones. Also, foldables introduce new display\ncapabilities, such as folding and unfolding, that can trigger [configuration\nchanges](/guide/topics/resources/runtime-changes). Your app needs to be able to restore state when these configuration\nchanges occur. You also then need to write tests that confirm your app restores\nstate correctly.\n**Figure 2.** Foldable device folded, open flat, open flat rotated to landscape, and half opened (tabletop).\n\nFirst, test that your app doesn't crash when configuration changes occur. Make\nsure that every UI in your app can handle any combination of rotating, resizing,\nor folding. Because configuration changes recreate the activity by default, some\ncrashes happen due to assumptions of activity persistence.\n\nThere are multiple ways to test configuration changes, but for most cases, there\nare two ways to test:\n\n- In Compose, use [`StateRestorationTester`](/training/testing/different-screens/tools#staterestorationtester) to simulate a configuration change in an efficient way without restarting the activity. See the following sections for more information.\n- In any UI test such as Espresso or Compose, simulate a configuration change by calling `Activity.recreate()`.\n\nYou generally don't have to use different devices to test state restoration in\nresponse to configuration changes. This is because all configuration changes\nthat recreate the activity have similar repercussions. However, some\nconfiguration changes might trigger different state restoration mechanisms on\nspecific devices.\n\nFor example, when a user is viewing a [list-detail UI](https://m3.material.io/foundations/layout/canonical-layouts/list-detail) on an open foldable\nand they fold the device to switch to the front display, the UI typically\nswitches to the detail page. An automated test should cover this restoration of\nthe UI state, including the navigation state.\n\nTo test configuration changes that happen on devices going from one display to\nanother or entering multi-window mode, you have multiple options:\n\n- Using any device, resize the screen during a test. In most cases, this triggers all the state restoration mechanisms that you need to verify. However, this test won't work for logic that detects specific postures in foldables, as posture changes don't trigger a configuration change.\n- Using a device or emulator that supports the features you want to test, trigger the related configuration changes. For example, a foldable or a tablet can be controlled using Espresso Device to move from folded to open flat in landscape. See the [Espresso Device](/training/testing/different-screens/tools#espresso-device) section of [Libraries and\n tools to test different screen sizes](/training/testing/different-screens/tools) for examples.\n\nYour browser doesn't support the video tag. **Figure 3.** Device folding and unfolding.\n\nTypes of tests for different screen and window sizes\n----------------------------------------------------\n\nUse the appropriate type of test for each use case to verify the test is working\ncorrectly across different form factors:\n\n- **UI behavior tests** launch some portion of the app UI, such as the display\n of an activity. The tests verify that certain elements exist or have\n specific attributes . The tests might optionally perform simulated user\n actions. For views, use [Espresso](/training/testing/espresso). Jetpack Compose has its own [testing\n APIs](/jetpack/compose/testing). UI behavior tests can be [instrumented](/training/testing/instrumented-tests) or [local](/training/testing/local-tests).\n Instrumented tests run on devices or emulators, while local UI tests run on\n [Robolectric](https://robolectric.org/) on the JVM.\n\n Use UI behavior tests to verify that an app's implementation of navigation\n is correct. The tests perform actions such as clicks and swipes. UI behavior\n tests also check the existence of certain elements or properties. For more\n information, see [Automate UI tests](/training/testing/ui-tests).\n- **Screenshot tests** take a screenshot of a UI or component and compare the\n image to a previously approved screenshot. This is a very effective way to\n protect against regressions, as a single screenshot can cover a large number\n of elements and its visual properties. You can run screenshot tests on the\n JVM or on devices. There are multiple screenshot test frameworks available.\n For more information, see [screenshot tests](/training/testing/screenshot).\n\nFinally, you might need unit tests to test the functionality of units of logic\nthat behave differently depending on the type of device or window size, but unit\ntests are less common in this area.\n\nNext steps\n----------\n\nFor more information about how to implement the checks contained in this\ndocument, see [Libraries and tools](/training/testing/different-screens/tools)."]]
