Offer a quick way to disable the BaristaRule retries

[rocboronat]

The BaristaRule is great, but when you are trying to develop a complex test, you want to just crash the test when it fails. "Ok, it doesn't work, I want to see the Espresso Exception... but I need to wait 10 fails :·D"

[Sloy]

Feel free to add it!

[rocboronat]

Same! 🥇

[EsteveAguilera]

Any hint about the best or desirable approach?

[rocboronat]

IMHO, this is a great way to use it:

@Rule public BaristaRule<MyActivity> baristaRule = BaristaRule.create(MyActivity.class).withoutRetries();

[EsteveAguilera]

Mmm... what about let the developers choose the number of max attempts?

[Sloy]

How 'bout

@Rule
public BaristaRule baristaRule = BaristaRule.for(MyActivity.class)
  .withRetries(5)
  .clearingSharedPreferences()
  .clearingDatabases()
  .clearingFiles()
  .withAllPermissions()
  .build();

But I'm still missing a clean way to setup the internal rules like ClearFiles and ClearDatabases.

[rocboronat]

Actually, focusing on the needed, the reason why I opened the issue (and I think that most devs need) is to just disable the retries when developing a new test.

@EsteveAguilera IMHO, the answer to the question is that it's a detail that is not too important. Or at least, right now :·D For me, I don't care if it's 5 or 10 retries. The only thing I need is to disable it when I'm developing a new test.

[EsteveAguilera]

Ok @rocboronat , I see what you mean. Maybe the title of the issue is not too descriptive, one thing is 'configure' and another one 'disable retries' 😝

[rocboronat]

Totally :·D Let's change the title

[rocboronat]

Sorry for the confusion, by the way 👉 👈

[Sloy]

BTW @rocboronat, if what you need is to disable retries for some new test while developing, you can overwrite the default retries by annotating the specific method:

@Test
@AllowFlaky(attempts = 1)
public void someNewTest() throws Exception {
}

Does this solve your needs in this issue @rocboronat?

[Sloy]

Toc toc @rocboronat. Does my last comment help with your pain? Or should we revisit the solutions?

[rocboronat]

Let's close the issue because the author doesn't answer. Whow, that's me! :·D

Thanks a lot for the solution, @Sloy

[rocboronat]

I need the feature again... 🙈

[Phixyn]

We need this feature too. I would be happy to help in any way I can 👍

[Sloy]

@rocboronat Cool! Does my comment from 14 Nov 2017 help with your new pain? :P

In a serious note, I would encourage you to use a custom rule instead of the Barista rule. It's great for quickly setting up UI tests, but falls short when you need more flexibility. That's what we started to do at Schibsted.

[Sloy]

That was my opinion, and if you don't like it... I have another!

Maybe adding an optional boolean parameter to the Rule constructor to enable/disable the flaky repetitions?

This is what we do at our project:

val DEFAULT_FLAKY_ATTEMPTS = BuildConfig.IS_CI ? 7 : 1
//...
flakyTestRule =FlakyTestRule().allowFlakyAttemptsByDefault(DEFAULT_FLAKY_ATTEMPTS)

That way the repetitions are done on CI builds only, and they are ignored when running tests locally.

The IS_CI constant comes from our build.gradle file like this:

android {
    defaultConfig {
        buildConfigField "boolean", "IS_CI", isTravis.toString()
    }
}

[rocboronat]

That's great @Sloy! Wise solution! 👏

Right now it seems that Firebase Test Cloud is so stable to not need the AllowFlaky feature. We just made a hard copy of the BaristaRule and replaced the 10 with a 1... but it's not an ideal solution. I think that this feature is the only one that needs to be disabled at will. The other magic done by the Rule is so great that (I hope) nobody will need to disable it.

BTW, don't worry about this issue. I'll do something when it would be that important.