Applying Testing Strategies — Determinism, Structure, and Hilt

A test suite needs three things to scale: it must be deterministic (same input → same outcome), structured (any reader can locate Given/When/Then), and replaceable (a single binding swap reroutes the production graph to fakes). This skill encodes Google's strategy guidance — flagging which page each rule actually lives on — and the Hilt mechanics that wire it into the build.

When to use this skill

• The user asks "how should I structure my Android tests" / "Given-When-Then or Arrange-Act-Assert" / "how do I name test methods".
• The user asks about @HiltAndroidTest, HiltAndroidRule, @TestInstallIn, @UninstallModules, @BindValue, or rule ordering.
• The user reports "tests pass locally but fail on CI" — usually a determinism / hermeticity issue.
• The user is starting a new module and needs a strategy doc / convention list.
• The user mentions RuleChain.outerRule for combining HiltAndroidRule with ActivityScenarioRule or composeTestRule.

When NOT to use this skill

• The user is choosing scope (small/medium/big) — use ../../concepts/understanding-the-testing-pyramid/SKILL.md.
• The user is choosing what behavior to cover — use ../../concepts/choosing-what-to-test/SKILL.md.
• The user is choosing fakes vs mocks — use ../../doubles/picking-test-doubles/SKILL.md.
• The user is wiring source sets — use ../organizing-test-source-sets/SKILL.md.
• The user is debugging a single flaky Compose animation test — use ../../../compose/synchronization/synchronizing-with-idle/SKILL.md.