Repository navigation
Make Espresso waits say what they are waiting for - #64
Merged
Merged
Conversation
Three CI failures in a row, all the same shape and none of them product bugs. The waiting helper was copied into three test classes. Fixing a flake in one left the identical code in the others failing, which is exactly what happened: the keyboard-over-the-button fix went into one login test and CI then failed on its sibling. It is one class now. The retry itself was also wrong. Retrying until nothing throws cannot tell "the tap missed, try again" from "the tap worked and has already torn the screen down" - Espresso reports the second as NoActivityResumedException from the same call, so the retry turned one success into fifty failures. That is what broke the post-merge run on main. Eventually.perform takes a condition saying what "it worked" means, usually a fake having been called, and stops the moment that holds regardless of what was thrown. Eventually.check keeps the old behaviour for assertions, where retrying until it holds is right. Documented in AGENTS.md with the two rules that came out of the same failures: one ViewAction per perform when the action may finish the flow, and a GONE view still matches withId. Two consecutive full runs green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
parawanderer
temporarily deployed
to
Android Build
August 12, 2026 19:59 — with
GitHub Actions
Inactive
parawanderer
temporarily deployed
to
Android Build
August 12, 2026 19:59 — with
GitHub Actions
Inactive
This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the instrumented job failing on
mainafter #62.Three CI failures in a row, all the same shape, none of them product bugs.
What was wrong
The waiting helper was copied into three test classes. A flake was found and
fixed in one; the identical code in the others kept failing. That is literally
what happened — the keyboard-over-the-button fix went into one login test, and
CI then failed on its sibling.
The retry was also wrong in a way copying could only spread. Retrying until
nothing throws cannot tell two opposite situations apart:
retried
Espresso throws
NoActivityResumedExceptionfrom the very same callRetrying the second turns one success into fifty failures. That is what broke
the post-merge run:
theConfiguredServerIsWhatTheSignInActuallyUsessigns inimmediately, so the click that worked also ended the activity.
The fix
One
Eventuallyclass, two methods, and picking the wrong one is the bug:Eventually.check(...)— assertions and waiting for views. Espresso waits forthe main thread and nothing else, while every step here runs on an Rx
scheduler.
Eventually.perform(what, tookEffect, action)— anything that changes thescreen. The caller states what "it worked" means, usually a fake having been
called, and it stops the moment that holds regardless of what was thrown.
Documented in AGENTS.md, along with two rules from the same failures: one
ViewActionperperformwhen the action may finish the flow, and aGONEview still matches
withId.Verification
Two consecutive full runs on the managed device, 106 tests, no failures. Since
the whole point is that this used to pass locally and fail in CI, the run on
this PR is the one that counts.
🤖 Generated with Claude Code