Introduction

In Android projects, src/test and src/androidTest serve different testing layers. src/test contains local JVM unit tests that run quickly without a device. src/androidTest contains instrumentation tests that run on an emulator or physical device with Android framework access. Choosing the correct folder affects execution speed, dependency availability, and test reliability.

Core Sections

src/test for local unit tests

These tests run on your machine's JVM.

1class MathUtilsTest {
2    @Test
3    fun addsNumbers() {
4        assertEquals(4, 2 + 2)
5    }
6}

Best for pure Kotlin/Java logic, mappers, validators, and isolated business rules.

src/androidTest for instrumentation tests

These tests run with Android runtime context.

1@RunWith(AndroidJUnit4::class)
2class LoginScreenTest {
3    @Test
4    fun showsLoginButton() {
5        onView(withId(R.id.loginButton)).check(matches(isDisplayed()))
6    }
7}

Use for UI tests, integration with Android components, and end-to-end behavior.

Dependency and runtime differences

• testImplementation dependencies are for src/test.
• androidTestImplementation dependencies are for src/androidTest.

Execution commands differ:

./gradlew test
./gradlew connectedAndroidTest

Test pyramid guidance

Keep most tests in src/test for speed. Add targeted instrumentation tests for critical Android integration paths.

CI considerations

Instrumentation tests are slower and require emulator/device orchestration. Parallelization and sharding help keep CI time acceptable.

Common Pitfalls

• Putting Android framework-dependent tests in src/test and hitting missing runtime classes.
• Overloading src/androidTest with logic that could be fast local unit tests.
• Misconfiguring dependencies between test source sets.
• Treating instrumentation tests as replacements for unit tests.
• Ignoring emulator stability and flakiness mitigation in CI.

Implementation Playbook

To make this topic production-ready, treat implementation as a repeatable workflow instead of a one-time fix. Start by defining an explicit baseline with known inputs, expected outputs, and measured runtime behavior. Baselines are critical because many regressions appear only after dependency upgrades, environment changes, or infrastructure shifts that do not modify application code directly. A baseline lets you detect drift quickly and determine whether a failure came from logic changes, runtime configuration, or platform behavior.

Next, design a small but representative validation matrix that covers happy-path, edge-case, and failure-path scenarios. Keep the matrix lightweight enough to run frequently, ideally in local development and CI, and strict enough to catch common integration mistakes. If this topic depends on external services, include deterministic stubs or contract fixtures so tests remain stable and actionable. For observability, log key identifiers, decision branches, and outcome statuses in a structured format; this allows fast correlation in dashboards and incident timelines without manual guesswork.

After correctness checks, add operational safeguards. Define timeout behavior, retry policy, and rollback triggers before rollout. Avoid making multiple high-risk changes simultaneously; apply one change, verify, then continue. Incremental rollout minimizes blast radius and produces clearer diagnostics when behavior diverges from expectations. In shared systems, publish a short runbook that lists prerequisites, expected metrics, and first-response troubleshooting steps. This documentation prevents repeated rediscovery work and improves handoff quality across teams.

Use the following execution checklist for consistent delivery:

11. Capture baseline behavior and expected outputs
22. Run happy-path, edge-case, and failure-path tests
33. Validate environment and dependency compatibility
44. Record structured logs and key performance metrics
55. Roll out incrementally with clear rollback criteria
66. Update runbook notes with observed outcomes

Change Control Note

Apply updates in small increments and verify each increment with one deterministic test run before proceeding. Incremental changes reduce rollback scope and make root-cause analysis faster if behavior shifts after dependency or configuration changes.

Final Validation Tip

Keep one short regression test tied to this exact behavior and run it whenever dependencies or runtime settings change.

Summary

src/test is for fast JVM unit tests, while src/androidTest is for device/emulator instrumentation tests. Use each layer intentionally to balance speed, coverage, and Android integration confidence.