Kakao Compose

Interceptors allow you to inject custom logic (like logging) or override Espresso calls. You can set interceptors at the global KakaoCompose runtime level or on individual BaseNode instances.

Interceptors are executed in descending order: Active BaseNode interceptor -> Parent BaseNode interceptor -> ... -> Kakao-Compose interceptor.

If an interceptor sets isOverride = true, the remaining interceptors are skipped and the actual Espresso call is not performed, giving the developer full control over the execution.

@Before
fun setup() {
    KakaoCompose {
        intercept {
            onComposeInteraction {
                onAll { list.add("ALL") }
                onCheck { _, _ -> list.add("CHECK") }
                onPerform { _, _ -> list.add("PERFORM") }
            }
        }
    }
}

@Test
fun testWithNodeInterceptor() {
    onComposeScreen<MyScreen> {
        myView {
            intercept {
                onPerform(true) { interaction, action -> 
                    // isOverride = true
                    Log.d("KAKAO_NODE", "Intercepted: $action")
                    interaction.perform(action) // Manually calling Espresso
                }
            }
        }
    }
}

Kakao Compose uses a hierarchical approach to represent the Jetpack Compose UI tree.

1. ComposeScreen: Represents a UI entity (a whole screen or a portion of it). It can be an abstraction or a specific Node by providing a viewBuilderAction (e.g., using hasTestTag).
2. KNode: Represents specific interactive elements within a screen.

Nodes can be defined as children of a ComposeScreen or as children of other KNodes. When a node is defined as a child, its SemanticMatcher is automatically composed of its own matchers plus the matchers of its parent(s), ensuring the test targets the correct element within the hierarchy.

class MainActivityScreen(semanticsProvider: SemanticsNodeInteractionsProvider) :
    ComposeScreen<MainActivityScreen>(
        semanticsProvider = semanticsProvider,
        viewBuilderAction = { hasTestTag("MainScreen") }
    ) {

    // myButton is a child of MainActivityScreen
    val myButton: KNode = child {
        hasTestTag("myTestButton")
    }

    // myButton2 is a child of myButton
    val myButton2: KNode = myButton.child {
        hasTestTag("myTestButton2")
    }
}

When using Kotlin Coroutines in Android apps, you can synchronize Espresso UI tests with asynchronous tasks by implementing a custom IdlingResource that monitors a CoroutineDispatcher. This ensures Espresso waits for background tasks (like network requests) to complete before performing assertions.

Implementation Steps:

1. Create a CoroutineIdlingResource: An implementation of IdlingResource that uses an AtomicInteger to track active coroutines.
2. Wrap the Dispatcher: Create an IdlingDispatcher that wraps a standard CoroutineDispatcher, calling increment() when a task is dispatched and decrement() when it finishes.
3. Inject the Dispatcher: Use the IdlingDispatcher within your application code (e.g., in a ViewModel) instead of default dispatchers like Dispatchers.IO during tests.
4. Register in Tests: Use Espresso.registerIdlingResources() in your @Before method and Espresso.unregisterIdlingResources() in your @After method.

// 1. Create the IdlingResource
class CoroutineIdlingResource : IdlingResource {
    private val counter = AtomicInteger(0)
    private var resourceCallback: IdlingResource.ResourceCallback? = null

    override fun getName(): String = CoroutineIdlingResource::class.java.name
    override fun isIdleNow(): Boolean = counter.get() == 0
    override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback?) {
        this.resourceCallback = callback
    }

    fun increment() = counter.getAndIncrement()
    fun decrement() {
        if (counter.decrementAndGet() == 0) {
            resourceCallback?.onTransitionToIdle()
        }
    }
}

// 2. Wrap the Dispatcher
class IdlingDispatcher(private val idlingResource: CoroutineIdlingResource) : CoroutineDispatcher() {
    private val dispatcher = Executors.newSingleThreadExecutor().asCoroutineDispatcher()
    override fun dispatch(context: kotlin.coroutines.CoroutineContext, block: Runnable) {
        idlingResource.increment()
        dispatcher.dispatch(context, Runnable {
            try { block.run() } finally { idlingResource.decrement() }
        })
    }
}

// 3. Use in ViewModel and Register in Test
@Test
fun testFetchData() {
    // Espresso will wait until the coroutine finishes because of the registered IdlingResource
    onView(withId(R.id.fetchDataButton)).perform(click())
    onView(withId(R.id.resultTextView)).check(matches(withText("Data Loaded")))
}

To create a Page Object, define a class that extends ComposeScreen. You must provide a semanticsProvider and a viewBuilderAction to locate the root of the screen (typically using hasTestTag). Inside the class, define elements as KNode properties using the child { ... } builder.

Important: Avoid Content Locators Do not use locators based on view content (e.g., hasText("Button 1")) as they are brittle. If the text changes, the test might fail or match the wrong element. Instead, use hasTestTag for stable identification.

class MainActivityScreen(semanticsProvider: SemanticsNodeInteractionsProvider) :
  ComposeScreen<MainActivityScreen>(
      semanticsProvider = semanticsProvider,
      viewBuilderAction = { hasTestTag("MainScreen") }) 
   {
  val myText1: KNode = child {
      hasTestTag("mySimpleText")
  }

  val clickCounter: KNode = child {
      hasTestTag("clickCounter")
  }
}