Forem: Ivan Shafran

Evolution of unit tests in Android

Ivan Shafran — Sun, 22 Oct 2023 21:19:47 +0000

In the article we take a look at the unit test evolution from beginner to pro-level. “Rate us” dialog is a popular feature, and it will be a good example. Typical “rate us” dialog has requirements like:

Should be shown after some condition or user action
Has “rate us” button that leads to Google Play
Has “remind me later” button that schedules dialog to show after some time(2 months in our case)
Has “never show again” button that hides the dialog forever

Zero version: no unit tests

At the beginning of the Android community, unit tests were not so popular. There are several arguments behind this:

Tests require time to be implemented and maintained
Apps were mostly simple
The framework itself isn’t friendly for writing unit tests

First version: my first unit test

But unfortunately, “rate us” dialog is a too vital feature to ignore unit tests. The more users leave reviews, the more new users your app gets. Also, it should not be annoying. Otherwise, people will leave 1-star reviews.

I’ve implemented a sample app that follows the logic described in the introduction. To trigger dialog, a user should click button two times. Check code in the repository.

To code first unit test, I had to do several things.

Learn a little about JUnit Framework

Feel free to skip this chapter if you are familiar with JUnit.

JUnit is the most popular testing framework for Java. It’s included in dependencies by default to all new Android projects:

dependencies {
    testImplementation 'junit:junit:4.12'
}

To write a test, you should create a class in test folder which is created by default and contains ExampleUnitTest.java. Usually, if devs test SomeClass , devs will name class with tests SomeClassTest . Moreover, most times, it belongs to the same Java package.

Let’s see a simple test. You should annotate all test methods with org.junit.Test . Android Studio will automatically show the run test button. assertEquals will throw an exception if arguments are not equal. JUnit marks test as passed if it ends without any exception.

Abstract an Android from business logic

In Android, you can’t write unit tests for a class that uses the Android framework. But wait… WHAT???!

Yes, the framework requires a specific environment and you can’t run it on any JVM. In unit tests, all Android classes are mocked to throw an exception. The best that we can do is to force it to return default values instead of throwing an exception.

// In application module build.gradle
android.testOptions {
    unitTests.returnDefaultValues = true
}

Back to the dialog, we certainly use Android classes like Activity/Fragment, View, Dialog, and others for “rate us” feature. Therefore we can’t write unit tests without a bit of effort.

First, I created an interface for every Android dependency which I use for “rate us” showing logic.

interface BuyPreferences {
    fun incrementBuyCount()
    fun getBuyCount(): Int
}

class BuyPreferencesImpl(context: Context) : BuyPreferences {
    // ...
    private val sharedPreferences: SharedPreferences = context.getSharedPreferences(...)

    override fun incrementBuyCount() {
        val count = getBuyCount()
        sharedPreferences.edit().putInt(BUY_COUNT_KEY, count + 1).apply()
    }

    override fun getBuyCount() = sharedPreferences.getInt(BUY_COUNT_KEY, 0)
}

Second, I created an interface for every Java dependency that can’t be used directly in tests. More specifically, it is System.currentTimeMillis() .

interface Time {
    fun getCurrentTimeMillis(): Long
}

class TimeImpl : Time {
    override fun getCurrentTimeMillis() = System.currentTimeMillis()
}

Last, I applied the dependency inversion principle toShowRateUsLogic.

class ShowRateUsLogic(
    private val rateUsPreferences: RateUsPreferences,
    private val buyPreferences: BuyPreferences,
    private val time: Time
) {
    fun shouldShowRateUs(): Boolean {
        val timeFromLastShown = time.getCurrentTimeMillis() - rateUsPreferences.getLastShownTimeMillis()
        return when {
            // User doesn't want to see "rate us" again
            rateUsPreferences.isNeverShownAgainClicked() -> false
            // User already rated the app
            rateUsPreferences.isRateNowClicked() -> false
            // "Rate us" should be shown after 2 "buy" clicked
            buyPreferences.getBuyCount() < 2 -> false
            // Show "rate us" only first time or if passed two months since last shown time
            timeFromLastShown < TimeUnit.DAYS.toMillis(60) -> false
            else -> true
        }
    }
}

Mocks

Now we should write mock classes for unit tests. I’ll show one mock below. You can check all the mocks here.

public class BuyPreferencesMock implements BuyPreferences {
    private int count;

    @Override public void incrementBuyCount() {
        ++count;
    }

    @Override public int getBuyCount() {
        return count;
    }
}

First unit test

After hardworking, it is a pleasure to code the first unit test :)

public class ShowRateUsLogicTest {
    private RateUsPreferencesMock rateUsPreferences;
    private BuyPreferencesMock buyPreferences;
    private TimeMock time;
    private ShowRateUsLogic showRateUsLogic;

    @Test public void test1() {
        rateUsPreferences = new RateUsPreferencesMock();
        buyPreferences = new BuyPreferencesMock();
        time = new TimeMock();
        showRateUsLogic = new ShowRateUsLogic(rateUsPreferences, buyPreferences, time);

        buyPreferences.incrementBuyCount();
        time.setCurrentTimeMillis(new Date(2019, 6, 7).getTime());

        Assert.assertFalse(showRateUsLogic.shouldShowRateUs());
    }
}

To be honest, it is not. But I wrote it in the “my first unit test” style. And I’ll fix it in the next chapters.

Second version: code cleaning

The first unit test is cool but if no one can understand it, then it is useless. Therefore I’ve refactored test class:

setUp is marked with @Before annotation. It makes the method to be invoked before every unit test. We’ll move the common test code to setUp method.
A good test method has a meaningful name. It’s better for reading and also it appears in test reports. We’ll rename test1 to onFirstCheckAndOneClickItShouldNotShow .
I’ve added a more complicated test. The test name is too short to express all the information. That’s why we’ll add comments to the method body.
For the last step, we’ll delete unnecessary and wrong time set.

public class ShowRateUsLogicTest {
    // property declaration is skipped
    @Before public void setUp() {
        rateUsPreferences = new RateUsPreferencesMock();
        buyPreferences = new BuyPreferencesMock();
        time = new TimeMock();
        showRateUsLogic = new ShowRateUsLogic(rateUsPreferences, buyPreferences, time);
    }

    @Test public void onFirstCheckAndOneClickItShouldNotShow() {
        buyPreferences.incrementBuyCount();

        Assert.assertFalse(showRateUsLogic.shouldShowRateUs());
    }

    @Test public void onThreeClicksAndItShouldShow() {
        // clicked three times
        buyPreferences.incrementBuyCount();
        buyPreferences.incrementBuyCount();
        buyPreferences.incrementBuyCount();
        // set first dialog show time
        final Calendar calendar = Calendar.getInstance();
        calendar.set(2019, Calendar.JULY, 7);
        rateUsPreferences.setLastShownTimeMillis(calendar.getTimeInMillis());
        // set current time to be 90 days after first show
        time.setCurrentTimeMillis(calendar.getTimeInMillis() + TimeUnit.DAYS.toMillis(90));

        Assert.assertTrue(showRateUsLogic.shouldShowRateUs());
    }
}

Third version: mocking libraries

As mentioned, we can not use Android classes in unit tests. But almost all our classes do it. And it’s quite boring to create an interface, an implementation and a mock for every class.

Fortunately, there is an alternative way. We can use mocking libraries.

Mockito

Directly to the most frequently used API:

Use Mockito.mock(Class) to mock any interface or class
Use Mockito.when(instance.method()).thenReturn(value) to mock method call
Use Mockito.verify(instance).method() to check if method was called

Shared preferences mock

In my practice, shared preferences class is the most used Android dependency in business logic. Therefore I’ve implemented shared preferences mock library which mimics Android implementation. Now you can use shared preferences in unit tests with one additional line of code ;)

public class ShowRateUsLogicTest {
    // property declaration is skipped
    @Before public void setUp() {
        final Context mockedContext = new SPMockBuilder().createContext();
        rateUsPreferences = new RateUsPreferencesImpl(mockedContext);
        buyPreferences = new BuyPreferencesImpl(mockedContext);
        time = Mockito.mock(Time.class);
        showRateUsLogic = new ShowRateUsLogic(rateUsPreferences, buyPreferences, time);
    }

    // first test code leaves the same

    // second test code changed only in time mocking
    @Test public void onThreeClicksAndItShouldShow() {
        // ...

        // set current time to be 90 days after first show
        Mockito.when(time.getCurrentTimeMillis()).thenReturn(calendar.getTimeInMillis() + TimeUnit.DAYS.toMillis(90));

        Assert.assertTrue(showRateUsLogic.shouldShowRateUs());
    }
}

Fourth version: Kotlin

Kotlin is a good language for Android development. And also, it can bring improvements to unit tests code.

We’ll rename the test method name using spaces enclosed in backticks
We’ll move the common preparation code to function with default arguments
We’ll delete unnecessary comments because we can use named arguments
We’ll use mockito-kotlin cause it has a more idiomatic and compact syntax

class ShowRateUsLogicTest {
    // property declaration and setup are skipped
    private fun prepareConditions(
        buyClickedTimes: Int = 0, 
        isNeverShownAgainClicked: Boolean = false,
        isRateNowClicked: Boolean = false, 
        lastShownTimeMillis: Long = 0, 
        currentTimeMillis: Long = 0
    ) {
        repeat(buyClickedTimes) { buyPreferences.incrementBuyCount() }
        if (isNeverShownAgainClicked) rateUsPreferences.setNeverShownAgainClicked()
        if (isRateNowClicked) rateUsPreferences.setRateNowClickedClicked()
        rateUsPreferences.setLastShownTimeMillis(lastShownTimeMillis)
        whenever(time.getCurrentTimeMillis()).thenReturn(currentTimeMillis)
    }

    @Test fun onFirstCheckAndOneClickItShouldNotShow() {
        prepareConditions(buyClickedTimes = 1)

        Assert.assertFalse(showRateUsLogic.shouldShowRateUs())
    }

    @Test fun onThreeClicksAndItShouldShow() {
        prepareConditions(
            buyClickedTimes = 3,
            lastShownTimeMillis = SOME_DAY_IN_MILLIS,
            currentTimeMillis = SOME_DAY_IN_MILLIS + MORE_THAN_TWO_MONTHS
        )

        Assert.assertTrue(showRateUsLogic.shouldShowRateUs())
    }
}

Fifth version: Spek

Spek is a unit testing framework for Kotlin which supports Specification and Gherkin style.

Personally, the crucial features of Spek are:

Ability to structure test due to condition
Ability to construct tests on the go(cause test code is a lambda, not a method)
I intentionally will not describe syntax because it is easy to understand. And if you are interested in Spek then check out this link.

class ShowRateUsLogicTest : Spek({
    // property declaration, setup and preparation are skipped
    describe("show rate us logic") {
        context("first conditions checks") {
            context("buy clicked once") {
                beforeEachTest {
                    prepareConditions(buyClickedTimes = 1)
                }

                it("should not show 'rate us'") {
                    Assert.assertFalse(showRateUsLogic.shouldShowRateUs())
                }
            }

            context("buy clicked two times") {
                beforeEachTest {
                    prepareConditions(buyClickedTimes = 2)
                }

                it("should show 'rate us'") {
                    Assert.assertTrue(showRateUsLogic.shouldShowRateUs())
                }
            }
        }

        context("'rate us' was shown already, and user clicked 'show me later' on the dialog") {
            context("less than two months passed and user clicks buy") {
                beforeEachTest {
                    prepareConditions(
                        buyClickedTimes = 3,
                        lastShownTimeMillis = SOME_DAY_IN_MILLIS,
                        currentTimeMillis = SOME_DAY_IN_MILLIS + LESS_THAN_TWO_MONTHS
                    )
                }

                it("should not show 'rate us' again") {
                    Assert.assertFalse(showRateUsLogic.shouldShowRateUs())
                }
            }

            context("more than two months passed and user clicks buy") {
                beforeEachTest {
                    prepareConditions(
                        buyClickedTimes = 3,
                        lastShownTimeMillis = SOME_DAY_IN_MILLIS,
                        currentTimeMillis = SOME_DAY_IN_MILLIS + MORE_THAN_TWO_MONTHS
                    )
                }

                it("should show 'rate us' again") {
                    Assert.assertTrue(showRateUsLogic.shouldShowRateUs())
                }
            }
        }
    }
})

Moreover, Spek generates a structured test report in Android Studio.

Bonus part

The article about unit tests in Android will not be full without several mentions. If you have more links to mention, please share them in comments and I’ll add them to the article.

Robolectric

Robolectric is a framework that brings fast and reliable unit tests to Android. Tests run inside the JVM on your workstation in seconds.

It is not a pure unit testing but allows us to test Android APIs without launching a device or emulator. On the other hand, it has a bigger test run time.

Assertion frameworks

‘Rate us’ dialog logic has boolean return value, therefore we used simple assertTrue or assertFalse. But for more complicated tests, there’s not enough flexibility in default assertions.

Hamcrest is a framework for writing matcher objects allowing ‘match’ rules to be defined declaratively.

assertThat(Math.sqrt(-1), is(notANumber()))

AssertJ — fluent assertions java library.

assertThat(frodo.getName()).isEqualTo("Frodo")

Truth makes your test assertions and failure messages more readable. Similar to AssertJ, it natively supports many JDK and Guava types, and it is extensible to others.

assertThat(notificationText).contains("testuser@google.com")

Android open source app secure build config

Ivan Shafran — Sun, 22 Oct 2023 19:37:46 +0000

TL;DR repository: https://github.com/IvanShafran/android-open-source-app-signing

By default Android app has debug build in which APK is signed automatically with debug keystore. But for a release build, you have to sign with a manually created keystore.

If you develop an open source app, you can’t keep a keystore together with code due to security reasons. You can easily exclude it in the .gitignore file, but in this case, your contributors won’t build an app in a release variant. It complicates open source development because some bugs can only be discovered in a release build. Moreover, you can’t run UI tests for release builds directly from a repository. Let’s solve the problem!

First step. Create two keystores

Create one keystore for production build with strong passwords. And create another for contributors with any password. Place them both in the main app module folder. For default created project folder is “app.”

How to generate keystore

At this point, add production.jks to .gitignore .

Second step. Create two property files

Create two properties files in the same folder as described below.



# Sign key alias for contributors.jks
releaseSignKeyAlias=key
# Sign key password for contributors.jks
releaseSignKeyPassword=password
# Path to contributors.jks
releaseStoreFilePath=./contributors.jks
# Keystore password for contributors.jks
releaseStorePassword=password

Also, create production.properties with production key and passwords.

At this point, add production.properties to .gitignore .

Third step. Add script

Add script listed below to the same folder and apply it in build.gradle. Script checks if production properties file exists in the folder and if it exists script uses production keystore otherwise contributors. That’s all magic :)

Don’t forget to add production.jks and production.properties to .gitignore .

settings.gradle:



def propertiesFilename = "production.properties"
if (!project.file(propertiesFilename).exists()) {
    propertiesFilename = "contributors.properties"
}

def signingProperties = new Properties()
signingProperties.load(new FileInputStream(file(propertiesFilename)))

android {
    signingConfigs {
        release {
            keyAlias signingProperties.releaseSignKeyAlias
            keyPassword signingProperties.releaseSignKeyPassword
            storeFile file(signingProperties.releaseStoreFilePath)
            storePassword signingProperties.releaseStorePassword
        }
    }
}

build.gradle:



...
apply from: 'signing.gradle'
...
android {
  ...
  buildTypes {
        release {
            signingConfig signingConfigs.release
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

Full sample here: https://github.com/IvanShafran/android-open-source-app-signing

Improve Android unit tests with shared preferences mock library

Ivan Shafran — Mon, 27 Feb 2023 02:17:07 +0000

TL;DR: Shared preferences mock is the lightweight library let you increase coverage of unit tests and simplify code for them with one line of code.

The problem

Unit test on Android uses a framework mock where every method throws UnsupportedOperationExceptionor does nothing depending on your settings in Gradle testOptions.

In unit tests, we mostly test business logic, which often depends on preferences. Therefore you should mock all classes which use SharedPreferencesinside. It is a lot of boilerplate in tests. Moreover, because of this limitation, we never test preferences class code. However, it also may have bugs.

The solution

The library implements SharedPreferences, Context.getSharedPreferences and Context.deleteSharedPreferences in memory using only Java API.

It allows you to use classes with shared preferences in unit tests as is and also to write tests for them.

Usage

Add it in your root build.gradle at the end of repositories:



allprojects {
    repositories {
        ...
        mavenCentral()
    }
}

Add the dependency to module build.gradle:



dependencies {
    testImplementation 'io.github.ivanshafran:shared-preferences-mock:1.2.4'
}

In most cases, preference class or preference utils depends on Context. In unit test instead of real Context pass Context created by new SPMockBuilder().createContext().

If you already have Context with some mocked methods, you can use new SPMockBuilder().wrapContext(preconfiguredContext).

If you need raw SharedPreferences use new SPMockBuilder().createSharedPreferences().

If thread safety is necessary for your test, then configure SPMockBuilder.setThreadSafe(true). It is false by default.

Sample

The sample below describes common code where logic uses preference class to check condition. In line 29 SPMockBuilder creates a context for the preference unit tests. Simple, isn’t it?



public class CounterPreferences {
    // ...
    private final SharedPreferences sharedPreferences;
    public CounterPreferences(@NonNull final Context context) {
        sharedPreferences = context.getSharedPreferences(FILENAME, Context.MODE_PRIVATE);
    }

    public int getCounter() {
        return sharedPreferences.getInt(KEY, 0);
    }
    // ...
}

public class ShowMessageLogic {
    // ...
    public boolean shouldShowMessage() {
        return counterPreferences.getCounter() >= 42;
    }
}

public class ShowMessageLogicTest {

    private final SPMockBuilder spMockBuilder = new SPMockBuilder();
    private CounterPreferences counterPreferences;
    private ShowMessageLogic showMessageLogic;

    @Before
    public void setUp() {
        counterPreferences = new CounterPreferences(spMockBuilder.createContext());
        showMessageLogic = new ShowMessageLogic(counterPreferences);
    }

    @Test
    public void on42CounterItShouldShowMessage() {
        counterPreferences.setCounter(42);
        Assert.assertTrue(showMessageLogic.shouldShowMessage());
    }

    @Test
    public void onLessThan42ItShouldNotShowMessage() {
        counterPreferences.setCounter(41);
        Assert.assertFalse(showMessageLogic.shouldShowMessage());
    }
}

Alternatives

Create CounterPreferences interface and implement Java version for a test by yourself:

Doesn’t test CounterPreferences implementation
Requires boilerplate code in tests

Use Mockito:

Doesn’t test CounterPreferences implementation

Use Robolectric:

Has test startup delay for a few seconds

Use instrumented test(not a unit test!):

Requires device for testing

The library and sample code

You can star the library and learn more info at:

IvanShafran / shared-preferences-mock

Library for unit testing shared preferences classes on Android

Shared Preferences Mock

Shared preferences mock is a lightweight library that lets you increase coverage of unit tests and simplify code for them with one line of code.

Motivation

Unit test on Android uses a framework mock where every method throws UnsupportedOperationException or does nothing depending on your settings in Gradle testOptions.

In unit tests, we mostly test business logic, which often depends on preferences. Therefore you should mock all classes which use SharedPreferences inside. It is a lot of boilerplate in tests. Moreover, because of this limitation, we never test preferences class code. However, it also may have bugs.

Under the hood

Under the hood the library implements SharedPreferences, Context.getSharedPreferences and Context.deleteSharedPreferences in memory using only Java API. Check the differences in the differences paragraph.

Download

Important: changed since 1.2.0

Add it in your root build.gradle at the end of repositories:

allprojects {
    repositories {
        mavenCentral()
    }

…

View on GitHub

Kotlin library development for Android/Java hints

Ivan Shafran — Sun, 19 Feb 2023 20:58:41 +0000

Kotlin versions support

When we develop a regular app for Android we can choose any Kotlin version. Some teams prefer to use the latest version in order to try new features and tooling improvements. Some teams wait some time before switching to a new version. It can be linked to a release cycle or waiting for community feedback on the last version.

But when we develop a library on Kotlin we have to support both versions. Luckily Kotlin has good forward and backward compatibility.

Backward compatibility

It’s simple:

All binaries are backwards compatible, i.e. a newer compiler can read older binaries (e.g. 1.3 understands 1.0 through 1.2) [1]

But it only applies to fully stable APIs: std-lib, coroutines. Check [2] for the full list.

Forward compatibility

There is such statement:

Preferably (but we can’t guarantee it), the binary format is mostly forwards compatible with the next feature release, but not later ones (in the cases when new features are not used, e.g. 1.3 can understand most binaries from 1.4, but not 1.5). [1]

Not very specific but in practice, my library which targets 1.3 works fine with 1.2 and even 1.1 std-lib without any changes. And it’s not working with 1.0 due to function reference feature which I used in the library code.

But if we want more strict guarantees Kotlin compiler provides two useful flags: apiVersion and languageVersion.[3]

-language-version X.Y - compatibility mode for Kotlin language version X.Y, reports errors for all language features that came out later.[4]

-api-version X.Y - compatibility mode for Kotlin API version X.Y, reports errors for all code using newer APIs from the Kotlin Standard Library (including the code generated by the compiler).[4]

In Gradle I’ve configured it as following:

tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).all {
    kotlinOptions {
        apiVersion = "1.2"
        languageVersion = "1.2"
    }
}

After that, you will probably see some compilation errors. In order to fix them, you should exclude new features usages and write useful extension/function/classes from 1.3 by yourself.

Library development version

You can use the latest Kotlin version in your development. Except for new language features (which we can’t use due to apiVersion and languageVersion) it also brings compiler and tooling improvements.

Dropping support of old versions

In my opinion, it is not healthy to support old versions too long. I would recommend maintaining stability only one version back. Also, you could check release dates in artifacts repository to decide which versions to support [5].

Package structure and visibility

A good library should hide all unnecessary classes, functions and properties from library users. Mostly you should prefer using private and internal modifiers for these situations.

In addition, it is recommended to move all your not public code in the package with name “internal”:

Also, by convention, packages named “internal” are not considered public API. [8]

Java compatibility

In most cases, Kotlin does all work for you. It creates get/setfor properties for example.

Currently, I’ve faced only one problem. If you declare a public property in companion from Java it is accessible via Sample.Companion.INSTANCE. To fix that use @JvmField annotation.

class Sample {
    companion object {
        @JvmField
        val INSTANCE = Sample()
    }
}

Kotlin dependency in pure Java project

An Android library which is distributed as aar doesn’t include its dependency. Therefore in pure Java project library users will get NoClassDefFoundError because your library depends on Kotlin std-lib. Thus you should write notices about that in the README file or docs.

But people don’t like to read docs a lot. I would suggest one trick below. Please share in comments your opinion is it a good practice or not?

Declare dependency checker:

public class DependencyChecker {
    public static void check() throws ClassNotFoundException {
        try {
            // Intrinsics exists in all std-lib versions
            Class.forName("kotlin.jvm.internal.Intrinsics");
        } catch (ClassNotFoundException e) {
            throw new ClassNotFoundException("Library depends on Kotlin std-lib.\n" +
                 "Add to dependencies: org.jetbrains.kotlin:kotlin-stdlib:x.y.z"
            );
        }
    }
}

Check dependency in the static initializer block:

class Sample {
    companion object {
        init {
            DependencyChecker.check()
        }
    }
}

And if someone forgets to include Kotlin std-lib dependency he will get the solution in a crash log not just error.

Fragment: getContext vs requireContext

Ivan Shafran — Fri, 17 Feb 2023 00:16:22 +0000

TLDR: use requireContext only when you are sure fragment is attached to its host(onResume, onViewCreated, etc).

The problem

Android team annotated some sdk methods with NonNull and Nullable in support library in 27.1.0. That change leads to warnings and errors like on the picture above.

Why did they do this?

At first sight it looks like adding more and more pain to android apps development. But actually this annotations help us to decrease crash rate.

getContext can return null when fragment isn’t attached to its host. Let’s take a look at two examples.

@Override
public void onResume() {
    super.onResume();
    Resources resources = getContext().getResources();
}

First sample shows us that as long as fragment is attached to its host(in onResume for example) it’s safe to use getContext without nullability checking.

@Override
public void onResume() {
    super.onResume();
    new Handler().postDelayed(new Runnable() {
        @Override
        public void run() {
            final Resources resources = getContext().getResources();
        }
    }, TimeUnit.SECONDS.toMillis(5));
}

The second one reveals potential NullPointerException. If after 5 seconds fragment isn’t attached to host, app is crashed.

So getContext Nullable annotation can prevent bugs like in the second sample. But it causes a useless warning in the first sample in Java and an error in Kotlin.

How should we fix this?

Firstly we should fix potentials bugs.

Find all places where fragment can be detached at some point of time
Change code like in the sample below

In Java:

Context context = getContext();
if (context == null) {
    // Handle null context scenario
} else {
    // Old code with context
}

In Kotlin:

val context: Context = this.context ?: return // or if block

Finally replace the rest with requireContext() which returns NonNull Context instead of getContext(). But keep in mind that requireContext() will throw an exception if fragment isn’t attached to its host. So you should use requireContext() with respect to fragment lifecycle.

Wrong fixes

In Java:

1.
// requireContext() does the same
Context context = getContext();
if (context == null) {
    throw new IllegalStateException("");
}

2.
// Warning supressing only hides the real problem
private void doSomething(@NonNull final Context context) {
}

@Override
public void onResume() {
    super.onResume();

    //noinspection ConstantConditions
    doSomething(getContext());
}

In Kotlin:

// It is similar to requireContext() but with NullPointerException
val context: Context = context!!

Other similar methods

getActivity vs requireActivity
getHost vs requireHost
getFragmentManager vs requireFragmentManager

Forem: Ivan Shafran

Evolution of unit tests in Android

Zero version: no unit tests

First version: my first unit test

Learn a little about JUnit Framework

Abstract an Android from business logic

Mocks

First unit test

Second version: code cleaning

Third version: mocking libraries

Mockito

Shared preferences mock

Fourth version: Kotlin

Fifth version: Spek

Bonus part

Robolectric

Assertion frameworks

Android open source app secure build config

First step. Create two keystores

Second step. Create two property files

Third step. Add script

Improve Android unit tests with shared preferences mock library

The problem

The solution

Usage

Sample

Alternatives

The library and sample code

IvanShafran / shared-preferences-mock

Library for unit testing shared preferences classes on Android

Shared Preferences Mock

Motivation

Under the hood

Download

Kotlin library development for Android/Java hints

Kotlin versions support

Backward compatibility

Forward compatibility

Library development version

Dropping support of old versions

Package structure and visibility

Java compatibility

Kotlin dependency in pure Java project

Links

Fragment: getContext vs requireContext

The problem

Why did they do this?

How should we fix this?

Wrong fixes

Other similar methods