What is the difference between test and androidTest source sets?

What's really being asked

This question checks whether you understand the execution environments and build pipeline boundaries in Android testing. A senior candidate should know that the two source sets are not arbitrary organizational folders but are wired to completely different test runners and target platforms. The interviewer wants to hear that you can choose the right source set based on whether a test needs the real Android system or can run on the local Java Virtual Machine without hardware overhead.

The full answer

A strong answer hits four things in order. First, state that the test source set is for local unit tests that execute on the workstation JVM during the standard test Gradle task, giving you fast feedback without device boot time. Second, mention that these tests should avoid Android framework dependencies when possible, but can use mocking libraries like Mockito or Robolectric to simulate Android classes when necessary. Third, state that androidTest is for instrumented tests that execute on an Android device or emulator during the connectedAndroidTest or deviceCheck Gradle task. Fourth, note that androidTest has access to the real Android framework, Application Context, file system, and hardware sensors, making it appropriate for integration tests, Room database tests, and UI tests with Espresso or Compose UI testing.

The mistakes people make

The biggest red flag is treating the directories as interchangeable or claiming the only difference is naming convention. Another mistake is saying that all tests under test are pure Java or Kotlin with zero Android references; in practice, Robolectric lives in test and provides simulated Android framework behavior. A third red flag is asserting that androidTest is exclusively for UI tests; it is also used for integration tests that need a real Context, SQLite database, or content provider. Finally, saying that test requires a connected device or emulator shows a fundamental misunderstanding of the local JVM runner and will immediately downgrade your rating.

What usually comes next

An interviewer might ask when you would use Robolectric versus an emulator test, probing your understanding of fidelity versus speed. They might also ask how to share test utilities between the two source sets using a sharedTest module or how test fixtures work in newer Android Gradle Plugin versions. Another common follow-up is asking about execution speed trade-offs, how to configure different dependency scopes for test versus androidTest in the build file, or how to run these suites in a continuous integration pipeline with or without emulators.

A concrete example

Imagine you are writing a ViewModel that formats a user profile from a repository. You would place the ViewModel logic test in the test source set because it can run on the JVM with a fake repository and a test coroutine dispatcher, completing in milliseconds. However, you would place the corresponding screen UI test in androidTest because it launches an Activity, inflates Compose layouts, and verifies click interactions against the real Android framework on a device or emulator, ensuring that the actual integration between the UI layer and the system works correctly.