Applying Testing Strategies

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.

Prerequisites

• Familiarity with the small/medium/big pyramid framing from ../../concepts/understanding-the-testing-pyramid/SKILL.md.
• A test target where dependencies are injected (Hilt, manual constructor injection, or another DI library).
• For the Hilt section: dagger.hilt.android.testing.HiltAndroidRule and dagger.hilt.android.testing.HiltAndroidTest available on androidTestImplementation.
• For determinism: kotlinx-coroutines-test, Robolectric (if host tests), and the ability to stub System.currentTimeMillis() / Clock.systemDefaultZone().

Source-of-truth map (which page says what)

Per tasks/research/R8-android-fundamentals.md, the strategy concepts live on three different pages. Naming the source matters because PR reviewers cite skills.

MUST NOT attribute determinism guidance to /strategies — it is on /instrumented-tests/stability. MUST NOT claim Google "recommends Given-When-Then" — the pages do not say that; they only use the comment style in samples.

Determinism

Per /training/testing/instrumented-tests/stability (and CORPUS §C "Common gotchas"), four sources of non-determinism dominate:

1. Time — System.currentTimeMillis(), Clock.systemDefaultZone(), Instant.now(). Inject a Clock or use kotlinx-coroutines-test's virtual time.
2. Concurrency / coroutines — direct Dispatchers.IO, runBlocking, real delay. Use runTest, inject CoroutineDispatcher, replace Dispatchers.Main via Dispatchers.setMain(dispatcher). See ../../../jvm-tests/coroutines/testing-coroutines-with-runtest/SKILL.md.
3. Animation / frame timing — Compose's MainTestClock, View animations. Disable via testOptions.animationsDisabled = true (Gradle) or Settings.Global.WINDOW_ANIMATION_SCALE = 0 (ADB). For Compose: mainClock.autoAdvance = false per the skydoves directives in docs/SPEC.md §5.
4. External state — network, real DB, Random(), UUID.randomUUID(). Inject seeds, use fakes, run pm clear before each instrumented test.

Concrete checklist:

• Clock (or equivalent time source) is injected; tests substitute Clock.fixed(Instant.parse(...), ZoneId.of("UTC")).
• Dispatchers are injected via a DispatcherProvider interface or replaced with Dispatchers.setMain(StandardTestDispatcher()) in a @Before.
• Random is seeded (Random(42)) or wrapped behind a RandomProvider that the test substitutes.
• testOptions.animationsDisabled = true is set in build.gradle.kts.
• CI runs pm clear <pkg> before every instrumented test (Test Orchestrator does this automatically; otherwise add an @Before).

Hermetic vs integration

The /strategies page does NOT formalize "hermetic" as a top-level term. The closest definition is on /test-doubles:

"A hermetic test avoids all external dependencies, such as fetching data from the internet." — developer.android.com/training/testing/fundamentals/test-doubles

The operational rule is on /strategies:

MUST NOT present "hermetic" as if it were a dedicated section on /strategies — it is mentioned in passing on /test-doubles only. MUST cite both pages when discussing hermeticity: /test-doubles for the term, /strategies for the operational rule.

Given-When-Then / Arrange-Act-Assert

Neither pattern is named on any of the four primary pages (/fundamentals, /what-to-test, /test-doubles, /strategies). They are visibly used in Google's code samples. From /fundamentals:

// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)

// When data is loaded
viewModel.loadData()

// Then it should be exposing data
assertTrue(viewModel.data != null)

— developer.android.com/training/testing/fundamentals (Local/host-side unit test example)

And from the same page:

// When the Continue button is clicked
onView(withText("Continue")).perform(click())
// Then the Welcome screen is displayed
onView(withText("Welcome")).check(matches(isDisplayed()))

— developer.android.com/training/testing/fundamentals (Espresso example)

Cite "Google's official samples consistently use Given-When-Then comment blocks" — accurate. Do NOT cite "Google recommends Given-When-Then" — that is fabrication.

Both Given-When-Then and Arrange-Act-Assert are the same shape with different vocabulary:

Given (Arrange) — set up the SUT and dependencies
When  (Act)     — invoke the behavior under test
Then  (Assert)  — assert on the resulting state or interaction

Pick one vocabulary per repo (skydoves preference: Given-When-Then, matching Google's samples). Use it as inline comment blocks, not as method names.

Test naming

The only verbatim naming guidance across the four primary pages is the backtick caveat on /instrumented-tests:

"Note: Using backticks to name tests in Kotlin is only supported on devices running API 30 and above." — developer.android.com/training/testing/instrumented-tests

Implications:

• Local tests (src/test/) — backtick names are safe (run on JVM, not the Android runtime).
• Instrumented tests (src/androidTest/) — backtick names require minSdk >= 30 on the test APK. Below that, use camelCase or snake_case_with_underscores.

skydoves convention (combine these two facts): a methodName_state_expected shape that reads as a sentence.

loadUsers_emptyList_emitsEmptyState
applyCoupon_negativeTotal_emitsError
save_orchestratorMarksDirtyOnce

Hilt for testing — the full mechanic

Source: developer.android.com/training/dependency-injection/hilt-testing plus CORPUS §F.6.

Why Hilt for tests at all

"Hilt isn't necessary for unit tests, since when testing a class that uses constructor injection, you don't need to use Hilt to instantiate that class." — developer.android.com/training/dependency-injection/hilt-testing

"For integration tests, Hilt injects dependencies as it would in your production code. Testing with Hilt requires no maintenance because Hilt automatically generates a new set of components for each test." — developer.android.com/training/dependency-injection/hilt-testing

So: constructor-inject in unit tests (skip Hilt), use Hilt in UI / integration tests.

@HiltAndroidTest + HiltAndroidRule ordered first

@HiltAndroidTest
class HomeScreenTest {
    @get:Rule(order = 0) val hiltRule = HiltAndroidRule(this)
    @get:Rule(order = 1) val composeRule = createAndroidComposeRule<MainActivity>()

    @Inject lateinit var userRepository: UserRepository

    @Before fun inject() = hiltRule.inject()
}

HiltAndroidRule MUST execute before any rule that touches the injected graph (Activity launch, Compose setup). The /hilt-testing page phrases this as "the HiltAndroidRule executes first". Lower order values run first in JUnit4 (@Rule(order = 0) outranks order = 1), so the conventional pattern is 0 then 1 as shown — but the rule is "Hilt first", not specifically "order = 0". Negative numbers also work (order = -1 paired with order = 0), and any monotonically increasing scheme is fine. Per /hilt-testing:

"You must annotate any UI test that uses Hilt with @HiltAndroidTest. This annotation is responsible for generating the Hilt components for each test. Also, you need to add the HiltAndroidRule to the test class." — developer.android.com/training/dependency-injection/hilt-testing

"To inject types into a test, use @Inject for field injection. To tell Hilt to populate the @Inject fields, call hiltRule.inject()." — developer.android.com/training/dependency-injection/hilt-testing