Day82 of #100DaysOfCode

Day82 of #100DaysOfCode

Hii folks 🙌

Today I will be continuing the same pathway in which we will write down the testcase for ViewModel.

Unit 3: Navigation

Pathway 3: Advanced navigation app Examples

Test ViewModels and LiveData

Let’s start with a simple test. The first thing we do when we interact with the app on a device or emulator is to select a quantity of cupcakes. So first we will test the setQuantity() method in the OrderViewModel, and check the value of the quantity LiveData object.

The quantity variable, which we are going to test, is an instance of LiveData. Testing LiveData objects requires an extra step, and this is where the dependency we added comes into play. We use LiveData to update our UI as soon as a value changes. Our UI runs on what we call the "main thread." If we are unfamiliar with threading and concurrency, that's okay, we'll go over it in depth in other codelabs. For the time being, in the context of an Android app, think of the main thread as the UI thread. The code that shows the UI to a user runs on this thread. Unless otherwise specified, a unit test assumes that everything runs on the main thread. However, because LiveData objects cannot access the main thread we have to explicitly state that LiveData objects should not call the main thread.

  • To specify that LiveData objects should not call the main thread we need to provide a specific test rule any time we are testing a LiveData object.
var instantTaskExecutorRule = InstantTaskExecutorRule()
  • Now we can create a function called quantity_twelve_cupcakes(). In the method, create an instance of the OrderViewModel.
  • In this test, we will be checking to make sure the quantity object in the OrderViewModel is updated when setQuantity is called. But before calling any methods or working with any data in the OrderViewModel, it is important to note that when testing the values of a LiveData object, the objects need to be observed in order for changes to be emitted. A simple way of doing this is by using the observeForever method. Call the observeForever method on the quantity object. This method requires a lambda expression, but that can be left empty.
  • Then call the setQuantity() method, passing in 12 as a parameter.
val viewModel = OrderViewModel()
viewModel.quantity.observeForever {}
  • We can safely infer that the value of the quantity object is 12. Note that LiveData objects are not the value itself. Values are contained in a property called value. Make the following assertion:
assertEquals(12, viewModel.quantity.value)

Our test should look like this:

fun quantity_twelve_cupcakes() {
val viewModel = OrderViewModel()
viewModel.quantity.observeForever {}
assertEquals(12, viewModel.quantity.value)

One of the main functions of the OrderViewModel is to calculate the price of our order. This happens when we select a number of cupcakes, and when we select a pickup date. The price calculation happens in a private method, so our test cannot call this method directly. Only other methods in the OrderViewModel can call it. Those methods are public, so we'll call those in order to trigger the price calculation so we can check that the value of the price is what we expect.

That is all for Day82 ✅

Thanks for reading, See you tomorrow!




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Mistake are Hard to Revert

Exception Handling in Flutter Apps

Do’s and don’ts when reporting a bug in Android Development

Dealing with flaky tests in Jetpack Compose

Adaptive Item Spacing in RecyclerView

Illustration of evenly spacing on RecyclerView’s item.

Make your Android application rock SOLID — Interfaces

Privileged applications in Android

Keeping your RecyclerView Adapter classes clean (Part 1)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kushagra Kesav

Kushagra Kesav

More from Medium

Day65 of #100DaysOfCode

Day86 of #100DaysOfCode

Day79 of #100DaysOfCode

Day76 of #100DaysOfCode