this might be a silly question, but those of you w...
# compose
j
this might be a silly question, but those of you who work on projects where unit tests are important but UI tests are much less common, what did you do when you started bringing in more and more Composables into your app? obviously the coverage drops significantly if you don’t write UI tests for everything because you now have a lot more kotlin code for Composables.. but I’m curious about what others have done. have you: • started being more strict about writing UI tests • not written UI tests and simply accepted the coverage % drop • something else?
k
I do not monitor test coverage and do not care that much about UI tests. From my exp unit tests are the ones to worry about.
👍 3
z
Adding UI Tests for composables, it was easier then I anticipated, and made coding the composables faster, since I just ran the tests and didn't have to compile the project and navigate to that UI element.
z
UI tests and unit tests are not mutually exclusive. You can write unit tests for UI, and compose makes doing so very easy. That said, I don’t think raw “coverage” is a very useful metric without context so pragmatically I wouldn’t be worried about this as long as you’re separating out changes that migrate ui to compose from changes to actual business or non-ui logic.
👍 1
c
You can write unit tests for UI
🤔 With jetpack compose though you still technically need to run those unit tests on the device right?
k
@Colton Idle I think you do, as most of the stuff in composable function reacts to user interaction. So if you wanna test if something changed, you must run device and interact with the screen. e.g.
Copy code
@Test
    fun should_call_sign_out_once_when_sign_out_button_clicked() {
        with(composeTestRule) {
            setContent { SignOutScreen(viewModel = viewModel) {} }
            val signOutButtonText = activity.getString(R.string.sign_out_button)
            onNodeWithText(signOutButtonText).performClick()
            verify { viewModel.signOut() }
        }
    }
z
If you need an activity/device/emulator I don't see how it is a unit test and not a UI test. Would you place it in the test package or in the androidTest package?
z
With jetpack compose though you still technically need to run those unit tests on the device right
Probably, although you may be able to run them with robolectric.
If you need an activity/device/emulator I don’t see how it is a unit test and not a UI test.
They are different axes. A “unit test” tests a “unit” of code, as opposed to an integration test which tests how multiple components interact. There are other types of tests on this axis as well (e.g. functional). A “unit” can be a non-UI bit of logic, or a single UI component, for example. A “UI test” tests some UI. That may be a single component (i.e. a unit UI test) or a whole navigation flow. Typically UI tests are ran on an emulator or device, although it might be possible in the future to run UI tests without a device/emulator (typically called “host-side”).
👍 1
z
So something like testing if a button changes color when clicked is both a UI test and a unit test?
z
If you’re actually only testing the button component itself with all its dependencies faked out, vs launching the app, navigating to a screen with the button, and clicking it, then yes
👍 2
j
thank you all for the detailed answers 🙏