Create compose base

[alorma]

Create barista-compose module and create first assertions.

assertDisplayed("Some text") && assertDisplayed(R.string.some_string)
assertNotDisplayed("Some text") && assertNotDisplayed(R.string.some_string)

Both depending on ComposeTestRule and `SemantincNodeInteraction``

So test will look:

  @Test
  fun assertIsDisplayed_StringTest() {
    composeTestRule.setContent {
      TextComposable("Hello world")
    }

    composeTestRule.assertDisplayed("Hello world")
  }

  @Test
  fun assertDisplayed_ResourceTest() {
    composeTestRule.setContent {
      TextComposable(stringResource(R.string.app_name))
    }

    composeTestRule.assertNotDisplayed(R.string.next)
  }

[costular]

Nice work, looks good to me 👌🏼
Just added some comments that could be an improvement

[costular]

I like it!

[costular]

Why not use text variable instead of hardcoded Barista text?

[rocboronat]

Same than before :·)

[rocboronat]

Hello! 👋

Same than @victormpineda : I would try to mimic Barista's API. Why don't call those methods assertDisplayed and instead of receiving named parameters, receive plain old ones? If you pass a text it's the hardcoded text, if you pass a int it's a R.string... It makes the API less verbose.

Thanks for the contribution, of course! It's a big step forward 💌

[Sloy]

+1 on the Barista-style API. My idea of a Barista for Compose would be to have the same simple straightforward human-readable API. Function names with a few words with a couple of parameters to perform the most common tasks.
What are the most common tasks? The ones in the existing Barista API! 😄

A more flexible or modularized API is cool too (I don't know if it's needed, I haven't tried Compose test API yet). But, in my opinion, it would be a different thing from Barista.

[costular]

Hello! 👋

Same than @victormpineda : I would try to mimic Barista's API. Why don't call those methods assertDisplayed and instead of receiving named parameters, receive plain old ones? If you pass a text it's the hardcoded text, if you pass a int it's a R.string... It makes the API less verbose.

Thanks for the contribution, of course! It's a big step forward 💌

If I'm not wrong there are different methods for hardcoded text and string resource. The named parameters are optional and related to the specific Compose API.

[rocboronat]

Hi @costular ! Right now, the API is like this:

assertDisplayed("Hello world");
assertDisplayed(R.string.hello_world);
assertDisplayed(R.id.button);
assertDisplayed(R.id.button, "Hello world")
assertDisplayed(R.id.button, R.string.hello_world)

[costular]

Hi @costular ! Right now, the API is like this:

assertDisplayed("Hello world");
assertDisplayed(R.string.hello_world);
assertDisplayed(R.id.button);
assertDisplayed(R.id.button, "Hello world")
assertDisplayed(R.id.button, R.string.hello_world)

Maybe you understood me wrong or I did. You said that you prefer to receive plain parameters and what I'm saying is this PR contains different methods for hardcoded and resource assertions (like you asked) plus Compose API arguments:

useUnmergedTree: Boolean = false,
substring: Boolean = false,
ignoreCase: Boolean = false

I think if we change the order of the arguments like this:

fun ComposeTestRule.assertDisplayed(
  @StringRes textRes: Int,
  useUnmergedTree: Boolean = false,
  substring: Boolean = false,
  ignoreCase: Boolean = false
)

We can do something like this:

// Plain
composeTestRule.assertDisplayed(R.string.some_text)
// Use unmerged tree which is part of Compose API
composeTestRule.assertDisplayed(R.string.some_text, useUnmergedTree = true)

What do you think?

[rocboronat]

Ah! Seems great! But we need an assertDisplayed() that receives the hardcoded value, too. So maybe this does the job?

fun ComposeTestRule.assertDisplayed(
  text: String,
  useUnmergedTree: Boolean = false,
  substring: Boolean = false,
  ignoreCase: Boolean = false
)
fun ComposeTestRule.assertDisplayed(
  @StringRes textRes: Int,
  useUnmergedTree: Boolean = false,
  substring: Boolean = false,
  ignoreCase: Boolean = false
)

[costular]

Ah! Seems great! But we need an assertDisplayed() that receives the hardcoded value, too. So maybe this does the job?

fun ComposeTestRule.assertDisplayed(
  text: String,
  useUnmergedTree: Boolean = false,
  substring: Boolean = false,
  ignoreCase: Boolean = false
)
fun ComposeTestRule.assertDisplayed(
  @StringRes textRes: Int,
  useUnmergedTree: Boolean = false,
  substring: Boolean = false,
  ignoreCase: Boolean = false
)

This would work perfectly!

[rocboronat]

What do you think, @alorma? Does it break your plans too much?

[alorma]

Hi everyone! Wow so great discussions here!

I won't be able to work on this until later today but yeah, your proposals look great.

Let me redo this PR applying your suggestions

[alorma]

Hello @rocboronat @Sloy @costular @victormpineda!(wow, so many contributors on this PR!!!)

I've applied all the comments suggested on the PR, so now the API matches barista style methods.

What do you think? Is ok as a first step to have a barista-compose API?

[costular]

@alorma Go ahead! IMHO it suits our needs for the first step with barista-compose. As soon as it's deployed we'll use it!

[costular]

@rocboronat @Sloy Any updates on this?

[rocboronat]

Let's use the same approach we did in the regular Barista, like composeTestRule.assertDisplayed("Hello world")

[alorma]

yes, removed it!

[rocboronat]

Hello @alorma! That's my only feedback. As soon as you update the tests or just add cases that call the assertDisplayed method by the regular way, without specifying the text, textRes and so on, feel free to merge it with your admin superpowers 💪

Congratulations on this PR! It's a step that will make lots of people happier 😄