• Mock: create a mock for GetAppConfigRepository using @Mock
• Argument Capture: We use argumentCaptor to capture the callbacks passed to getConfig so we can invoke them manually in the test.
• Spies: spy(testObject) allows us to verify the internal method calls (onSuccess and onFailure) while preserving the logic of the UseCase class.

Test Cases:

• Success Case: The test checks if save is called when onSuccess is triggered.
• Failure Case: The test checks if logError is called with the correct parameters when onFailure is triggered.

Required Dependencies

// Unit testing libraries
testImplementation 'junit:junit:4.13.2'
testImplementation 'org.mockito:mockito-core:3.11.2'
testImplementation 'org.mockito:mockito-inline:3.11.2'
testImplementation "org.jetbrains.kotlin:kotlin-test:1.5.21"
testImplementation "org.jetbrains.kotlin:kotlin-test-junit:1.5.21"

Conclusion

Unit testing is a crucial part of Android development, ensuring that individual components work as expected without relying on external systems. By using mocks and spies, you can isolate your code, control dependencies, and write fast, reliable tests.

• Mocks replace real objects with fakes to control their behavior.
• Spies wrap around real objects to monitor or modify their behavior during tests.

With this knowledge, you can now confidently implement unit tests in your Android projects using mocks and spies in Kotlin!

Besides mock and spy, there are several other techniques, tools, and practices that support and enhance unit testing in Android development with Kotlin. These help in writing more efficient, maintainable, and reliable tests. Here’s an overview of additional concepts and tools that support unit testing:

1. Stubs

• What is it? A stub is a simplified implementation of a class or method that returns hard-coded data. Unlike mocks, stubs do not verify interactions or behavior; they are just placeholders that provide predefined responses.
• When to use: Use stubs when you need a predictable and simple result without focusing on how it’s called.

class FakeUserRepository : UserRepository {
    override fun getUserById(userId: String): User {
        // Returning a hard-coded user for testing
        return User("1", "Jane Doe")
    }
}

Stubs are useful when you don’t need the flexibility of mocks, but just want simple data for your test cases.

2. Fake Objects

• What is it? A fake is a simple, usually in-memory implementation of an interface or class, which mimics the behavior of the real object. Fakes are used when creating the real object is too expensive (e.g., database connections, network calls).
• When to use: Use fakes to simulate interactions with external systems, like databases or APIs, but with simplified behavior.

class InMemoryUserRepository : UserRepository {
    private val users = mutableListOf<User>()

    override fun getUserById(userId: String): User {
        return users.find { it.id == userId } ?: throw NoSuchElementException("User not found")
    }

    fun addUser(user: User) {
        users.add(user)
    }
}

Here, InMemoryUserRepository is a fake that mimics the real repository but uses an in-memory list to simulate database functionality.

3. Test Fixtures

• What is it? A fixture is a known set of data or objects that is used to ensure tests run with consistent inputs. Test fixtures make sure that your test runs in a controlled environment by setting up the necessary preconditions.
• When to use: Use fixtures when you need a specific state or set of data before running your tests, ensuring consistency across different tests.

class UserServiceTest {

    private lateinit var userService: UserService
    private lateinit var mockRepository: UserRepository

    @Before
    fun setup() {
        mockRepository = mock(UserRepository::class.java)
        `when`(mockRepository.getUserById("1")).thenReturn(User("1", "John Doe"))
        userService = UserService(mockRepository)
    }

    @Test
    fun `should return user name correctly`() {
        val userName = userService.getUserName("1")
        assertEquals("John Doe", userName)
    }
}

In this case, the @Before annotated method setup() acts as a fixture by initializing and configuring the necessary objects before each test.

4. Assertions

• What is it? Assertions are used to check the correctness of the test’s results. They are critical in verifying that the expected outcomes match the actual results. Frameworks like JUnit provide built-in assertions, while libraries like Hamcrest and Truth offer more expressive and readable assertions.
• When to use: Use assertions in every test to verify that the actual output matches the expected behavior.

Example using JUnit Assertions:

@Test
fun `should return user name correctly`() {
    val userName = userService.getUserName("1")
    assertEquals("John Doe", userName)
}

Example using Hamcrest:

import org.hamcrest.CoreMatchers.`is`
import org.hamcrest.MatcherAssert.assertThat

@Test
fun `should return user name correctly`() {
    val userName = userService.getUserName("1")
    assertThat(userName, `is`("John Doe"))
}

Hamcrest’s assertThat() is more readable and is especially useful for complex assertions.

5. Parameterized Tests

• What is it? A parameterized test allows you to run the same test with different sets of data. This is useful when you want to test multiple cases without duplicating test logic.
• When to use: Use parameterized tests when you need to verify a method or class with multiple inputs and outputs.

import org.junit.Test
import org.junit.runner.RunWith
import org.junit.runners.Parameterized
import org.junit.Assert.assertEquals

@RunWith(Parameterized::class)
class CalculatorTest(private val input1: Int, private val input2: Int, private val expected: Int) {

    companion object {
        @JvmStatic
        @Parameterized.Parameters
        fun data() = listOf(
            arrayOf(1, 2, 3),
            arrayOf(2, 3, 5),
            arrayOf(5, 5, 10)
        )
    }

    private val calculator = Calculator()

    @Test
    fun `test addition`() {
        assertEquals(expected, calculator.add(input1, input2))
    }
}

This allows you to test the Calculator.add() method with various inputs without writing multiple test methods.

6. Test Doubles (Dummies)

• What is it? A test double is a general term for any object used in place of a real one in unit tests. Mocks, stubs, and fakes are all forms of test doubles. Dummies are a type of test double that is passed around but never actually used. They are only there to satisfy parameter requirements.
• When to use: Use dummies when you need to provide an argument but don’t care about its behavior during the test.

class OrderServiceTest {
    @Test
    fun `should process order`() {
        val dummyCustomer = Customer(id = "123")  // Not used, just to satisfy the signature
        val orderService = OrderService(dummyCustomer)
        orderService.processOrder()
    }
}

7. Timeouts

• What is it? A timeout specifies the maximum duration that a test is allowed to run before being forcibly terminated. This ensures that your tests do not hang indefinitely.
• When to use: Use timeouts to avoid long-running tests, especially when dealing with asynchronous code or network operations.

@Test(timeout = 1000)  // Test will fail if it runs longer than 1 second
fun `test method with timeout`() {
    Thread.sleep(500)  // This will pass
}

8. Code Coverage Tools

• What is it? Code coverage tools help you measure how much of your code is exercised by your unit tests. Tools like JaCoCo can show you what percentage of your code is covered by tests and highlight areas that are not being tested.
• When to use: Use code coverage tools to identify untested parts of your codebase and improve your test suite.

// Add the following to your build.gradle to enable JaCoCo:

apply plugin: 'jacoco'

jacoco {
    toolVersion = "0.8.7"
}

tasks.jacocoTestReport {
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

// Run the following to generate a coverage report:
./gradlew test jacocoTestReport

9. Test Runners

• What is it? A test runner is a component that orchestrates the execution of your test cases. In Android, the default test runner is AndroidJUnitRunner, but you can also use custom runners like Robolectric for simulating Android components in unit tests.
• When to use: Use a test runner to execute and manage your tests, particularly when you have special requirements like testing UI or Android components.

10. Robolectric

• What is it? Robolectric is a framework that allows you to run Android tests on the JVM without the need for an emulator or real device. It provides shadow implementations of Android APIs.
• When to use: Use Robolectric to test Android components (like Activity, Fragment, View) in isolation without requiring a device or emulator.

@RunWith(RobolectricTestRunner::class)
class MainActivityTest {

    @Test
    fun `should display correct text`() {
        val activity = Robolectric.buildActivity(MainActivity::class.java).create().get()
        val textView = activity.findViewById<TextView>(R.id.text_view)
        assertEquals("Hello World!", textView.text.toString())
    }
}

References:

• Mockito Documentation
• https://github.com/mockito/mockito
• https://martinfowler.com/articles/mocksArentStubs.html
• Unit Testing in Android

https://github.com/nphausg?source=post_page—–66e23b0e330b——————————–

This article is previously published on proandroiddev.com