이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Espresso 유휴 리소스
컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

유휴 리소스는 결과가 영향을 미치는 비동기 작업을 나타냅니다. UI 테스트의 후속 작업을 처리합니다. 유휴 리소스를 Espresso에서 이러한 비동기 작업의 유효성을 검사하는 경우 매우 유용합니다.

유휴 리소스가 필요한 경우 식별

Espresso는 다음과 같은 정교한 작업 세트를 제공합니다. 동기화 기능이 필요합니다. 이 그러나 프레임워크의 특성은 MessageQueue의 메시지(예: 화면에 콘텐츠를 그리는 View입니다.

Espresso는 다음을 비롯한 다른 비동기 작업을 인식하지 못하기 때문입니다. Espresso가 애플리케이션 동기화를 제공할 수 없으므로 보장이 없습니다 Espresso가 앱의 장기 실행 작업의 경우 각 작업을 유휴 리소스로 등록해야 합니다.

앱의 결과를 테스트할 때 유휴 리소스를 사용하지 않는 경우 비동기 작업을 하는 경우 테스트 결과를 개선하기 위해 잘못된 해결 방법을 따르는 경우 안정성:

Thread.sleep() 호출 추가: 테스트에 인위적인 지연을 추가하면 테스트 모음이 실행할 때 경우에 따라서는 테스트가 실패할 수 있습니다. 안 됩니다. 또한 이러한 지연이 제대로 확장되지 않습니다. 더 많은 시간이 소요되는 비동기 작업을 수행해야 합니다.
루프를 사용하여 반복 여부를 확인하는 재시도 래퍼 구현 앱은 시간 초과가 발생할 때까지 비동기 작업을 계속 실행합니다. 심지어 테스트에서 최대 재시도 횟수를 지정하면 재실행 시마다 특히 CPU입니다.
CountDownLatch 인스턴스 사용 특정 수의 작업이 실행될 때까지 하나 이상의 스레드가 대기하도록 허용 완료될 때까지 기다릴 필요가 없습니다. 이러한 객체를 사용하려면 먼저 제한 시간 길이 그러지 않으면 앱이 무기한 차단될 수 있습니다. 걸쇠 코드가 불필요하게 복잡해져서 유지보수가 더욱 어려워집니다.

Espresso를 사용하면 테스트 환경에서 이러한 신뢰할 수 없는 해결 방법을 삭제하고 대신 앱의 비동기 작업을 유휴 리소스로 등록하세요.

일반적인 사용 사례

테스트에서 다음 예와 유사한 작업을 수행할 때 유휴 리소스를 사용해 보세요.

인터넷 또는 로컬 데이터 소스에서 데이터 로드
데이터베이스 및 콜백과의 연결 설정
서비스 관리(시스템 서비스 또는 IntentService입니다.
복잡한 비즈니스 로직 실행(예: 비트맵 변환)

이러한 작업이 실행될 때 유휴 리소스를 등록하는 것이 특히 중요합니다. 테스트에서 유효성을 검사하는 UI를 업데이트합니다.

유휴 리소스 구현 예

다음 목록은 유휴 리소스의 몇 가지 구현 예를 설명합니다. 앱에 통합할 수 있습니다.

CountingIdlingResource: 활성 작업의 카운터를 유지 관리합니다. 카운터가 0이면 관련 유휴 상태로 간주됩니다 이 기능은 Semaphore 대부분의 경우 이 구현은 테스트 중에 앱의 비동기 작업을 관리하는 데 충분합니다.
UriIdlingResource: 비슷함 CountingIdlingResource, 하지만 유휴 상태로 간주됩니다 이 추가 대기 기간이 연속해서 네트워크 요청을 고려할 때 스레드의 앱이 새 요청을 만들 수 있는 경우 이전 요청에 대한 응답을 수신한 직후 요청을 전송합니다.
IdlingThreadPoolExecutor: ThreadPoolExecutor의 맞춤 구현 생성된 스레드 내에서 실행 중인 작업의 총 수를 추적하는 있습니다. 이 클래스는 CountingIdlingResource(으)로 활성 작업의 카운터를 유지합니다.
IdlingScheduledThreadPoolExecutor: ScheduledThreadPoolExecutor Kubernetes는 Kubernetes에서 제공하는 IdlingThreadPoolExecutor 드림 클래스와 같지만 미래에 예약된 작업 또는 정기적으로 실행되도록 예약됩니다

를 통해 개인정보처리방침을 정의할 수 있습니다.

자체 유휴 리소스 만들기

앱 테스트에서 유휴 리소스를 사용할 때 커스텀 리소스 관리 또는 로깅이 포함되어 있습니다 이 경우 구현은 충분하지 않을 수 있습니다. 이러한 경우 이러한 유휴 리소스 구현 중 하나를 확장하거나 직접 만들 수 있습니다.

자체 유휴 리소스 기능을 구현하는 경우 다음을 최대한 유지하세요. 특히 첫 번째 관행을 염두에 두세요.

유휴 검사 외부에서 유휴 상태로의 전환을 호출합니다.: 앱이 유휴 상태가 되면 다음을 호출합니다. onTransitionToIdle() Google Cloud 콘솔의 isIdleNow()입니다. 이렇게 하면 Espresso는 주어진 컨텍스트가 제대로 작동하는지 판단하기 위해 유휴 리소스가 있는지 확인해야 합니다

다음 코드 스니펫은 이 권장사항을 보여줍니다.

Kotlin

fun isIdle() {
    // DON'T call callback.onTransitionToIdle() here!
}

fun backgroundWorkDone() {
    // Background work finished.
    callback.onTransitionToIdle() // Good. Tells Espresso that the app is idle.

    // Don't do any post-processing work beyond this point. Espresso now
    // considers your app to be idle and moves on to the next test action.
}

자바

public void isIdle() {
    // DON'T call callback.onTransitionToIdle() here!
}

public void backgroundWorkDone() {
    // Background work finished.
    callback.onTransitionToIdle() // Good. Tells Espresso that the app is idle.

    // Don't do any post-processing work beyond this point. Espresso now
    // considers your app to be idle and moves on to the next test action.
}

필요하기 전에 유휴 리소스를 등록합니다.

유휴 리소스와 관련된 동기화 이점은 다음과 같은 경우에만 적용됩니다. Espresso가 해당 리소스의 첫 번째 호출을 실행한 후 isIdleNow() 메서드를 사용하여 지도 가장자리에 패딩을 추가할 수 있습니다.

다음 목록은 이 속성의 몇 가지 예를 보여줍니다.

@Before 주석이 달린 메서드에서 유휴 리소스를 등록하는 경우 유휴 리소스는 각 테스트의 첫 번째 줄에 적용됩니다.
테스트 내에 유휴 리소스를 등록하면 유휴 리소스가 다음 Espresso 기반 작업 중에 적용됩니다. 이 동작은 여전히 다음 작업이 유휴 리소스를 등록합니다

유휴 리소스 사용을 완료한 후 유휴 리소스의 등록을 취소합니다.

시스템 리소스를 절약하려면 즉시 유휴 리소스의 등록을 취소해야 합니다. 리소스를 삭제할 수 있습니다 예를 들어 유휴 리소스를 등록하는 경우 @Before 주석이 달린 메서드에서 경우 이 리소스의 등록을 취소하는 것이 가장 좋습니다. @After 주석이 지정된 해당 메서드를 호출합니다.

유휴 레지스트리를 사용하여 유휴 리소스를 등록하고 등록 취소합니다.

앱의 유휴 리소스에 이 컨테이너를 사용하여 필요에 따라 유휴 리소스를 반복적으로 등록 취소하고 일관된 관찰 확인할 수 있습니다

단순 앱 상태만 유휴 리소스 내에서 유지 관리합니다.

예를 들어 구현하고 등록하는 유휴 리소스가 View 객체에 대한 참조를 포함합니다.

유휴 리소스 등록

Espresso는 앱의 유휴 상태를 배치할 수 있는 컨테이너 클래스를 제공합니다. 리소스를 배포합니다 이 클래스는 IdlingRegistry은 앱에 최소한의 오버헤드를 도입하는 독립 실행형 아티팩트입니다. 클래스 앱의 품질을 개선하기 위해 다음과 같은 조치를 취할 수 있습니다. 유지관리:

유휴 리소스 대신 IdlingRegistry 참조를 만듭니다. 를 포함하는 것이 좋습니다.
사용하는 유휴 리소스 컬렉션의 차이 유지 빌드 변형이 있습니다
UI가 아닌 앱의 서비스에서 유휴 리소스를 정의합니다. 해당 서비스를 참조하는 구성 요소입니다.

를 통해 개인정보처리방침을 정의할 수 있습니다.

유휴 리소스를 앱에 통합

여러 가지 방법으로 유휴 리소스를 앱에 추가할 수 있지만, 특히 앱의 캡슐화를 유지하면서 주어진 유휴 리소스가 나타내는 특정 작업을 지정할 수 있습니다.

권장 방법

앱에 유휴 리소스를 추가할 때는 앱 자체에서 유휴 리소스 로직을 포함하고 등록 및 등록 취소 작업을 실행할 수 있습니다.

테스트 전용 인터페이스를 사용하는 특이한 상황이 생기더라도 배포하지 않아도 되는 경우, 유휴 리소스를 사용하여 앱의 APK 크기와 메서드 수를 유지할 수 있습니다.

대체 방법

앱의 프로덕션에 유휴 리소스 로직을 포함하지 않으려는 경우 다른 여러 통합 전략이 있습니다.

Gradle의 빌드 변형과 같은 제품 flavor로 설정하고, 앱의 디버그 빌드에서만 유휴 리소스를 사용합니다.
Dagger와 같은 종속 항목 삽입 프레임워크를 사용하여 앱의 유휴 상태를 삽입합니다. 리소스 종속 항목 그래프를 테스트에 삽입해야 합니다. Dagger 2를 사용하는 경우 삽입 자체는 하위 구성요소에서 시작되어야 합니다.
앱 테스트에서 유휴 리소스를 구현하고 해당 부분을 노출합니다. 동기화해야 하는 앱 구현의 있습니다

주의: 이 디자인 결정은 유휴 리소스에 대한 독립 실행형 참조를 만들면 가장 단순한 앱을 제외한 모든 앱에서 캡슐화가 가능합니다.

추가 리소스

Android 테스트에서 Espresso를 사용하는 방법에 관한 자세한 내용은 확인할 수 있습니다

샘플

IdlingResourceSample: 백그라운드 작업과의 동기화.