ViewModel testing in Android Kotlin - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the main purpose of testing a ViewModel in Android?

To verify that the ViewModel correctly manages UI-related data and business logic without depending on the Android framework.

beginner

Which testing framework is commonly used for unit testing ViewModels in Kotlin?

JUnit is commonly used for unit testing ViewModels in Kotlin, often combined with libraries like Mockito for mocking dependencies.

intermediate

Why should LiveData be observed using a TestObserver or similar in ViewModel tests?

Because LiveData is lifecycle-aware, it needs a way to emit values in tests without a real lifecycle owner; TestObserver helps capture emitted values for assertions.

intermediate

What is the role of the InstantTaskExecutorRule in ViewModel testing?

It makes LiveData execute each task synchronously during tests, so you can immediately observe changes without waiting for background threads.

intermediate

How do you test a ViewModel function that updates LiveData based on a repository call?

Mock the repository to return expected data, call the ViewModel function, then observe the LiveData and assert it has the expected updated value.

Which rule helps LiveData run synchronously in ViewModel tests?

A InstantTaskExecutorRule

B ActivityScenarioRule

C CoroutineTestRule

D EspressoRule

InstantTaskExecutorRule forces LiveData to execute tasks synchronously, making it easier to test.

What should you mock when testing a ViewModel that depends on a repository?

A The Android framework

B The repository

C The ViewModel

D The UI components

Mocking the repository isolates the ViewModel logic and controls the data returned for testing.

Why is it important to avoid Android framework dependencies in ViewModel tests?

A Because ViewModels don't use Android framework

B Because Android framework is always buggy

C To test UI components instead

D To make tests faster and more reliable

Avoiding Android framework dependencies makes unit tests faster and easier to run without device or emulator.

Which of these is NOT a good practice when testing LiveData in ViewModels?

A Using a TestObserver to capture LiveData emissions

B Mocking dependencies that provide data

C Observing LiveData with a real lifecycle owner in unit tests

D Using InstantTaskExecutorRule

Using a real lifecycle owner in unit tests is difficult; TestObserver or similar tools are preferred.

What does a typical ViewModel test verify?

A That LiveData updates correctly after calling ViewModel functions

B That the UI layout looks correct

C That the app launches without crashing

D That the database schema is correct

ViewModel tests focus on logic and data updates, especially LiveData changes.

Explain how you would test a ViewModel method that fetches data asynchronously and updates LiveData.

Think about isolating dependencies and capturing LiveData changes.

Describe the purpose and use of InstantTaskExecutorRule in ViewModel testing.

Consider how LiveData normally works with lifecycle and threads.

Practice

1.

What is the main purpose of testing a ViewModel in Android development?

easy

A. To validate user input directly on the screen

B. To verify the data handling and business logic without UI involvement

C. To test the navigation between different screens

D. To check the layout and visual appearance of the app

Solution

1. Step 1: Understand ViewModel role

   The ViewModel holds and manages UI-related data but does not handle UI rendering.

2. Step 2: Identify testing focus

   Testing ViewModel focuses on data logic and state management, not UI or navigation.

3. Final Answer:

   To verify the data handling and business logic without UI involvement -> Option B

4. Quick Check:

   ViewModel testing = data logic check [OK]

Hint: ViewModel tests focus on data, not UI or navigation [OK]

Common Mistakes:

• Confusing ViewModel testing with UI testing
• Thinking ViewModel tests check screen layouts
• Assuming navigation is tested in ViewModel tests

2.

Which annotation is commonly used to set up a ViewModel instance before each test method runs?

easy

A. @Ignore

B. @Test

C. @After

D. @Before

Solution

1. Step 1: Recall JUnit lifecycle annotations

   @Before runs before each test method to prepare test environment.

2. Step 2: Match annotation to ViewModel setup

   Use @Before to initialize ViewModel before tests run.

3. Final Answer:

   @Before -> Option D

4. Quick Check:

   Setup before tests = @Before [OK]

Hint: Use @Before to prepare ViewModel before each test [OK]

Common Mistakes:

• Using @Test instead of @Before for setup
• Confusing @After with setup annotation
• Skipping setup annotation entirely

3.

Given the following test code snippet, what will be the value of result after running the test?

class MyViewModelTest {
  private lateinit var viewModel: MyViewModel

  @Before
  fun setup() {
    viewModel = MyViewModel()
  }

  @Test
  fun testIncrement() {
    viewModel.increment()
    val result = viewModel.counter
  }
}

Assuming counter starts at 0 and increment() adds 1.

medium

A. 1

B. 0

C. null

D. Throws an exception

Solution

1. Step 1: Understand initial state

   ViewModel's counter starts at 0 before increment.

2. Step 2: Apply increment method

   Calling increment() adds 1, so counter becomes 1.

3. Final Answer:

   1 -> Option A

4. Quick Check:

   Initial 0 + 1 increment = 1 [OK]

Hint: Increment adds 1 to counter starting at 0 [OK]

Common Mistakes:

• Assuming counter remains 0 after increment
• Thinking result is null without initialization
• Expecting an exception without error in code

4.

Identify the error in this ViewModel test code snippet:

class SampleViewModelTest {
  private lateinit var viewModel: SampleViewModel

  @Test
  fun testReset() {
    viewModel.reset()
    assertEquals(0, viewModel.counter)
  }
}

Assuming viewModel is not initialized anywhere else.

medium

A. Missing @Before setup to initialize viewModel before test

B. Incorrect assertEquals parameter order

C. reset() method does not exist in ViewModel

D. Test method missing @Test annotation

Solution

1. Step 1: Check viewModel initialization

   viewModel is declared but never initialized before test runs.

2. Step 2: Identify missing setup

   Without @Before method to initialize viewModel, calling reset() causes error.

3. Final Answer:

   Missing @Before setup to initialize viewModel before test -> Option A

4. Quick Check:

   Initialize viewModel before test = @Before needed [OK]

Hint: Always initialize ViewModel before tests with @Before [OK]

Common Mistakes:

• Forgetting to initialize viewModel before use
• Mixing assertEquals parameter order
• Assuming reset() method is missing without checking

5.

You want to test a ViewModel method that fetches data asynchronously and updates a LiveData property. Which approach is best to test this behavior?

hard

A. Mock the LiveData property and verify it was called

B. Call the method and immediately check LiveData value without waiting

C. Use a coroutine test rule to run suspend functions and observe LiveData changes synchronously

D. Test only the UI observing the LiveData, not the ViewModel method

Solution

1. Step 1: Understand asynchronous data fetching

   ViewModel uses coroutines to fetch data and update LiveData asynchronously.

2. Step 2: Use coroutine test tools

   Coroutine test rules allow running suspend functions in tests synchronously for reliable assertions.

3. Step 3: Observe LiveData changes properly

   Observing LiveData synchronously ensures test waits for updates before asserting values.

4. Final Answer:

   Use a coroutine test rule to run suspend functions and observe LiveData changes synchronously -> Option C

5. Quick Check:

   Async ViewModel test = coroutine test rule + LiveData observe [OK]

Hint: Use coroutine test rule to handle async LiveData updates [OK]

Common Mistakes:

• Checking LiveData immediately without waiting
• Mocking LiveData instead of testing real updates
• Testing UI instead of ViewModel logic