IssueTracker

Could you provide a small sample to illustrate the scenario you would like to test, and the thing that's not possible to test now?

Yes, for example I have a Fragment with a Compose UI, set up like this:

class FooFragment : Fragment() {
    private lateinit var binding: FragmentFooBinding
    private val viewModel: FooViewModel by viewModels()
    private val args: FooFragmentArgs by navArgs()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        binding.composeView.setContent {
            MdcTheme {
                FooScreen(viewModel)
            }
        }
        viewModel.onAction(FooActions.OnViewCreated(args))
    }

    override fun onPause() {
        viewModel.onAction(FooActions.OnPause)
        super.onPause()
    }
}

What I'm doing right now in my Compose test is that I manually trigger the specific actions to either feed the arguments to my ViewModel or to manually trigger the OnPause lifecycle action. This however doesn't test the real implementation! Since the fragment code isn't run, I cannot verify that I trigger the specific actions in the right lifecycle methods (or, that anybody moved things around).

Similar issues arise once I want to trigger and test for jetpack navigation events via a TestNavController, i.e. testing regular nav graphs in conjunction with the VM / Fragment calling code.

Hi, is this still a Won't Fix for you? This issue is still present and needs awkward workarounds.

Apologies, this slipped off my radar.

If you add the FooFragment to a test activity and then use createAndroidComposeRule<YourTestActivity>(), it should execute everything necessary to get the activity in the resumed state, which includes onViewCreated.

For onPause, however, you need a little more control. What you can do there is create an "empty" compose test rule, one that does not start an activity for you at all, and move your fragment through all states manually (like you would do for View-based UIs). For example:

@get:Rule
val composeRule = createEmptyComposeRule()

@Test
fun test() {
  with(launchFragmentInContainer<FooFragment>()) {
    // composeRule.onNode(..).assert(..), etc
    moveToState(State.STARTED)
    // assertions, etc.
  }
}

The problem is really interaction. The OnViewCreated action would kick-off a change that would result in a change of the downstream state that FooScreen would subscribe to. I assume that even though I'd add FooFragment to the Activity-under-test, I'd still have to call composeRule.setContent {}, because the Fragment's setContent call on the ComposeView still knows nothing of the Recomposer from the test rule, so these two things would still be detached from one another.

That's what I was referring to - if the current implementation of AndroidComposeTestRule would be a bit more open and would also allow the wrapping of ComposeView intances (from Activitys, Fragments or else), it would be of much help, especially for cases where developers weren't able to convert a complete screen to Compose yet, but start bottom up with small building blocks, like single views or fragments.

My go-to-solution is now to have a separate Fragment test that mocks out the ViewModel and tests the interactions in isolation, and then have another Compose+ViewModel test which does the other part.

Ah, I think I see the misunderstanding now.

You don't need to call AndroidComposeTestRule.setContent if your Activity or Fragment already sets the content. If you look closely to the return type of createEmptyComposeRule(), you'll find that it doesn't even have a setContent method.

The test rule takes care of wiring everything together. If you're interested to see how, take a look at this line. The only thing you have to make sure is that your Fragment or Activity calls setContent after the test rule is initialized. This can usually only go wrong if you instantiate your Fragment or Activity with another test rule that happens to run before the ComposeTestRule. For example, this would go wrong:

@get:Rule(order = 0)
val activityScenarioRule = ActivityScenarioRule<CustomActivity>()

@get:Rule(order = 1)
val composeTestRule = createEmptyComposeRule()

Please take a look at https://r.android.com/1986026 for guidance how to setup your test (same as comment#8).

Many thanks for the example, will try that out!

A small addition - when my Fragment is in Lifecycle.State.STARTED, compose will tell me this:

java.lang.IllegalStateException: No compose views found in the app. Is your Activity resumed?
	at androidx.compose.ui.test.TestContext.getAllSemanticsNodes$ui_test_release(TestOwner.kt:96)
	at androidx.compose.ui.test.SemanticsNodeInteraction.fetchSemanticsNodes$ui_test_release(SemanticsNodeInteraction.kt:82)
	at androidx.compose.ui.test.SemanticsNodeInteraction.fetchOneOrDie(SemanticsNodeInteraction.kt:155)
	at androidx.compose.ui.test.SemanticsNodeInteraction.fetchSemanticsNode(SemanticsNodeInteraction.kt:106)
	at androidx.compose.ui.test.AndroidAssertions_androidKt.checkIsDisplayed(AndroidAssertions.android.kt:29)
	at androidx.compose.ui.test.AssertionsKt.assertIsDisplayed(Assertions.kt:33)

If I move my Fragment to Lifecycle.State.RESUMED, this error is gone, which is fine for me; I don't need to test things before onResume.

I do call setContent on the ComposeView in onViewCreated, as per your example.

when my Fragment is in Lifecycle.State.STARTED, compose will tell me this

That is by design. If you open multiple activities we only want to find Compose elements in the RESUMED activity as that is the one the user is looking at.

If there is a good reason why the test harness should look in STARTED activities (/fragments) as well, then please open a new bug and I'll take a look.

What I also figured is that each test that does anything with composeRule runs quite slow, i.e. each test method needs about two extra seconds to run. I looked at the profile, but cannot say for sure whats causing this. What I can see however is that a test with the Activity-based rule takes about 150 to 250ms to execute with Robolectric, when I use the empty test rule the test takes about 2100 to 2300ms. Unfortunately I couldn't reproduce it yet with a smaller example. Will further have to look into this.

That is by design. If you open multiple activities we only want to find Compose elements in the RESUMED activity as that is the one the user is looking at.

No, this is totally fine. The error message could only a tad bit better by saying "Is your Activity or Fragment resumed?", other than that this is fine.

I created a follow-up issue 219980301 for a DialogFragment-related crash.