AndroidHire

Android Unit Testing Interview Questions

JUnit, mocking, and test design.

50 questions in this topic · 8 sample questions below

Practice Unit Testing in the quiz engine

Sample questions

  1. Where do local unit tests (src/test) run compared to instrumented tests (src/androidTest)?

    • Local unit tests run on the JVM of your development machine; instrumented tests run on a device or emulator — correct
    • Both run on a connected device or emulator
    • Local unit tests run on the device; instrumented tests run on the JVM
    • Both run on the JVM with a real Android framework linked in

    Why: Local unit tests execute on the host JVM and are fast but lack a real Android framework, while instrumented tests run on an emulator or device where the framework is available. The claim that both run the same way ignores this fundamental split.

  2. Why does calling an Android framework method like Log.d directly from a plain local unit test throw an exception by default?

    • Because local tests need the INTERNET permission to log
    • Because android.jar on the unit-test classpath is a stub whose methods throw Not mocked by default — correct
    • Because Logcat is unavailable off-device so logging is silently skipped
    • Because Gradle strips all android imports from test source sets

    Why: The android.jar used for local unit tests contains stubbed methods that throw a Method not mocked RuntimeException unless returnDefaultValues or Robolectric is used. It is not about permissions, which have no bearing on host-JVM stubs.

  3. In the classic taxonomy of test doubles, what distinguishes a fake from a stub?

    • A fake always throws, a stub always returns null
    • A fake is generated by a mocking framework, a stub is hand-written
    • A fake has a working but simplified implementation; a stub just returns canned answers to specific calls — correct
    • There is no difference; the terms are interchangeable

    Why: A fake has real, working behavior taken as a shortcut (e.g. an in-memory repository), whereas a stub merely returns pre-programmed responses to calls made during the test. Treating them as interchangeable erases the behavioral-vs-canned distinction that guides which to pick.

  4. What primarily distinguishes a mock from a spy?

    • A spy cannot verify calls, only a mock can
    • A mock wraps a real instance; a spy is fully synthetic
    • They are identical in MockK but differ in Mockito
    • A mock verifies interactions and is fully faked by default; a spy wraps a real object and calls real methods unless stubbed — correct

    Why: A spy delegates to the real object except where you override behavior, while a mock is a synthetic double whose interactions you typically verify. Saying a spy cannot verify is wrong: spies support the same verification API.

  5. A test creates a mockk of the exact class it is trying to test and stubs the method under test. What is the core problem?

    • You are testing the mock's stubbed behavior, not the real production code, so the test verifies nothing meaningful — correct
    • MockK cannot mock final classes so it will not compile
    • Spies are always faster than mocks so this is merely a performance issue
    • The test will pass only on instrumented runs

    Why: Mocking the class under test replaces the real logic with canned answers, so the assertions merely confirm the stub you wrote. MockK actually can mock final classes by default, so the compile claim is false.

  6. Why are fakes often preferred over mocks for a repository dependency in ViewModel tests?

    • Mocks run only on instrumented tests
    • A fake keeps real, stateful behavior so tests stay robust to refactors, while heavy mocking couples tests to exact call sequences and becomes brittle — correct
    • Fakes give you compile-time null safety that mocks lack
    • Fakes require no code, mocks require a lot

    Why: A fake repository behaves like the real thing (storing and returning data), so tests survive internal refactors, whereas over-specified mocks break when call order or internal methods change. Fakes usually require more code to write, not less.

  7. What does a relaxed mock in MockK provide that a strict mock does not?

    • It relaxes thread-safety checks
    • It disables verification entirely
    • It automatically returns sensible default values for unstubbed calls instead of throwing — correct
    • It converts the mock into a spy

    Why: A relaxed mock returns defaults (0, empty string, empty collections, a relaxed child mock) for any call you did not explicitly stub, avoiding MissingMethodInvocation errors. It does not turn the object into a spy nor disable verify.

  8. Which MockK construct is required to stub a suspend function?

    • every { }
    • verify { }
    • mockkStatic()
    • coEvery { } — correct

    Why: Suspend functions must be stubbed with coEvery and verified with coVerify because these open a coroutine-capable stubbing scope. Plain every cannot call a suspend function in its lambda.

Practice all 50 Unit Testing questions

These 8 are a sample. The full Unit Testing bank is scored, tracks your progress, and explains every answer.

Open the quiz

More Android interview topics