테스트는 앱 개발 프로세스에서 빼놓을 수 없는 부분입니다. 일반적으로 에뮬레이터나 기기에서 앱을 실행하여 코드가 예상대로 작동하는지 수동으로 확인합니다.
하지만 수동 테스트는 시간이 오래 걸리고 오류가 발생하기 쉬우며 다양한 크기의 화면과 기기에서 실행되는 앱의 경우 관리하기 어려운 경우가 많습니다. 수동 테스트의 문제는 개발에 단일 기기를 사용하는 데서 비롯되는 경우가 많습니다. 따라서 폼 팩터가 다른 기기에서는 오류가 눈에 띄지 않을 수 있습니다.
다양한 창 및 화면 크기에서 회귀를 식별하려면 자동화된 테스트를 구현하여 다양한 폼 팩터에서 앱의 동작과 모양이 일관적인지 확인하세요. 자동화된 테스트는 문제를 조기에 식별하여 사용자 환경에 영향을 미치는 문제의 위험을 완화합니다.
테스트 대상
다양한 화면 및 창 크기에 맞게 UI를 개발할 때는 다음 두 가지 측면에 특히 주의해야 합니다.
다양한 창 크기에 맞게 UI를 맞춤설정하는지 여부와 관계없이 UI가 올바르게 표시되는지 확인해야 합니다. 소형, 중형, 확장형 너비와 높이를 고려합니다. 권장 중단점은 창 크기 클래스를 참고하세요.
그림 1. 다양한 창 크기의 Now In Android '추천' 화면
또한 크기 제약 조건이 늘어날 때 디자인 시스템의 일부 구성요소가 예상대로 렌더링되지 않을 수도 있습니다.
앱에 다양한 창 크기에 맞는 적응형 레이아웃이 있는 경우 회귀를 방지하기 위한 자동 테스트가 있어야 합니다. 예를 들어 휴대전화의 여백을 수정하면 태블릿에서 레이아웃 불일치가 발생할 수 있습니다. UI 테스트를 만들어 레이아웃과 구성요소의 동작을 확인하거나 스크린샷 테스트를 구성하여 레이아웃을 시각적으로 확인합니다.
상태 복원
태블릿과 같은 기기에서 실행되는 앱은 휴대전화의 앱보다 훨씬 더 자주 회전되고 크기가 조절됩니다. 또한 폴더블은 접기 및 펼치기와 같은 새로운 디스플레이 기능을 도입하여 구성 변경을 트리거할 수 있습니다. 이러한 구성 변경이 발생할 때 앱은 상태를 복원할 수 있어야 합니다. 그런 다음 앱이 상태를 올바르게 복원하는지 확인하는 테스트를 작성해야 합니다.
그림 2. 접힌 상태, 평평하게 펼친 상태, 펼쳐서 가로 모드로 회전한 상태, 절반을 펼친 상태 (탁자 모드)의 폴더블 기기
먼저 구성이 변경될 때 앱이 비정상 종료되지 않는지 테스트합니다. 앱의 모든 UI가 회전, 크기 조절 또는 접기의 모든 조합을 처리할 수 있는지 확인합니다. 구성 변경으로 인해 기본적으로 활동이 다시 생성되므로 활동 지속성 가정으로 인해 일부 비정상 종료가 발생합니다.
구성 변경사항을 테스트하는 방법은 여러 가지가 있지만 대부분의 경우 테스트하는 방법은 두 가지입니다.
Compose에서는 StateRestorationTester를 사용하여 활동을 다시 시작하지 않고 효율적인 방식으로 구성 변경을 시뮬레이션합니다. 자세한 내용은 다음 섹션을 참고하세요.
Espresso 또는 Compose와 같은 UI 테스트에서 Activity.recreate()를 호출하여 구성 변경을 시뮬레이션합니다.
일반적으로 구성 변경에 대한 응답으로 상태 복원을 테스트하기 위해 다른 기기를 사용할 필요는 없습니다. 활동을 다시 만드는 모든 구성 변경사항이 비슷한 영향을 미치기 때문입니다. 하지만 일부 구성 변경사항은 특정 기기에서 다른 상태 복원 메커니즘을 트리거할 수 있습니다.
예를 들어 사용자가 펼쳐진 폴더블에서 목록-세부정보 UI를 보고 기기를 접어 전면 디스플레이로 전환하면 UI가 일반적으로 세부정보 페이지로 전환됩니다. 자동화된 테스트는 탐색 상태를 비롯한 UI 상태의 복원을 다루어야 합니다.
한 디스플레이에서 다른 디스플레이로 이동하거나 멀티 윈도우 모드로 전환되는 기기에서 발생하는 구성 변경사항을 테스트하는 방법은 여러 가지가 있습니다.
테스트 중에 기기를 사용하여 화면 크기를 조절합니다. 대부분의 경우 이렇게 하면 확인해야 하는 모든 상태 복원 메커니즘이 트리거됩니다.
하지만 이 테스트는 폴더블에서 특정 자세를 감지하는 로직에는 작동하지 않습니다. 자세 변경은 구성 변경을 트리거하지 않기 때문입니다.
테스트하려는 기능을 지원하는 기기 또는 에뮬레이터를 사용하여 관련 구성 변경사항을 트리거합니다. 예를 들어 폴더블이나 태블릿은 Espresso 기기를 사용하여 접힌 상태에서 가로로 평평하게 열린 상태로 이동할 수 있습니다. 예는 다양한 화면 크기를 테스트하는 라이브러리 및 도구의 Espresso 기기 섹션을 참고하세요.
그림 3. 기기 접기 및 펼치기
다양한 화면 및 창 크기에 대한 테스트 유형
각 사용 사례에 적합한 테스트 유형을 사용하여 다양한 폼 팩터에서 테스트가 올바르게 작동하는지 확인합니다.
UI 동작 테스트는 활동 표시와 같은 앱 UI의 일부를 실행합니다. 테스트에서는 특정 요소가 있는지 또는 특정 속성이 있는지 확인합니다 . 테스트는 선택적으로 시뮬레이션된 사용자 작업을 실행할 수 있습니다. 뷰의 경우 Espresso를 사용합니다. Jetpack Compose에는 자체 테스트 API가 있습니다. UI 동작 테스트는 계측되거나 로컬일 수 있습니다.
계측 테스트는 기기 또는 에뮬레이터에서 실행되는 반면 로컬 UI 테스트는 JVM의 Robolectric에서 실행됩니다.
UI 동작 테스트를 사용하여 앱의 탐색 구현이 올바른지 확인합니다. 테스트에서는 클릭, 스와이프와 같은 작업을 실행합니다. UI 동작 테스트는 특정 요소나 속성의 존재 여부도 확인합니다. 자세한 내용은 UI 테스트 자동화를 참고하세요.
스크린샷 테스트는 UI 또는 구성요소의 스크린샷을 찍고 이미지를 이전에 승인된 스크린샷과 비교합니다. 단일 스크린샷으로 많은 요소와 시각적 속성을 다룰 수 있으므로 회귀를 방지하는 데 매우 효과적인 방법입니다. JVM 또는 기기에서 스크린샷 테스트를 실행할 수 있습니다. 사용 가능한 스크린샷 테스트 프레임워크는 여러 개입니다.
자세한 내용은 스크린샷 테스트를 참고하세요.
마지막으로 기기 유형이나 창 크기에 따라 다르게 동작하는 논리 단위를 테스트하기 위해 단위 테스트가 필요할 수 있지만 이 영역에서는 단위 테스트가 덜 일반적입니다.
다음 단계
이 문서에 포함된 검사를 구현하는 방법에 관한 자세한 내용은 라이브러리 및 도구를 참고하세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-08-21(UTC)
[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)."]]
