UI-tests are a necessary part of our development routine in AUTO1. Although that wasn’t the case a while ago. One of the issues, which was blocking developers from writing and running UI-tests, was the need to set up UI-tests. Of course, to test the screen in isolation you need to have some architecture, employ the SOLID principles, especially Dependency inversion. With proper architecture it’s easy to substitute dependencies inside screen under the test with fakes or mocks. But even with good architecture you need to provide these mock implementations. And it’s not always obvious how to make your DI framework to provide mocks for tests.
\nRecently we started a brand new project from scratch. And we decided to give Koin a try. Why Koin and not Dagger? — Just because Koin offers concise and minimalistic syntax and it uses Kotlin. Also, important for us was the question of code generation. Although Google announced that in new versions of Android Gradle plug-in they made kapt incremental, we still didn’t want to add this extra burden to our build process. Simultaneously Koin 2.0 was announced at the same time. That’s how we found ourselves facing question: how to provide mock dependencies to our UI-tests?
\nInside our fragments we inject number of dependencies, typically they include viewmodels:
\nprivate val fragmentViewModel: EmailLoginFragmentViewModel by viewModel()That’s exactly what we want to substitute with mocks. To do so we need a custom Application class, which will start Koin with our test module, not the real one.
\nclass KoinTestApp: Application() {\n override fun onCreate() {\n super.onCreate()\n startKoin {\n androidLogger()\n androidContext(this@KoinTestApp)\n modules(emptyList())\n }\n }\n\n internal fun injectModule(module: Module) {\n loadKoinModules(module)\n }\n}We start our Koin instance inside onCreate() method, and we pass emptyList() of modules. We also have a method injectModule() which accepts our test module. Since we already started our application, we are using method loadKoinModules() to add this test module to the graph.
But we need to somehow start our test application class. We cannot use AndroidManifest inside androidTest folder, because manifest merger will ignore it if we set our test application inside Manifest like this: <application name=\".KoinTestApp\">. So we could use a custom test runner for that purpose. AndroidJUnitRunner class has a newApplication() method. And we can pass our test application name there, making our test runner to start our test application instead of a real one.
class KoinTestRunner: AndroidJUnitRunner() {\n override fun newApplication(\n cl: ClassLoader?, \n className: String?, \n context: Context?): Application {\n return super.newApplication(cl, KoinTestApp::class.java.name, context)\n }\n}Then we need to change our build.gradle inside our app module:
android {\n defaultConfig {\n …\n …\n testInstrumentationRunner “path.to.your.package.KoinTestRunner”\n }\n}And don’t forget to disable animations for UI-tests:
\nandroid {\n testOptions {\n animationsDisabled = true\n }\n}We are almost done. We only need to write our test and provide our test module to it. We are using our custom fragment test rule, which provides a couple of methods for submitting your fragment and mock test module. But you could use the same approach for activities.
\nabstract class FragmentTestRule<F: Fragment>: \n ActivityTestRule<FragmentActivity>(FragmentActivity::class.java, true) {\n \n override fun afterActivityLaunched() {\n super.afterActivityLaunched()\n activity.runOnUiThread {\n val fm = activity.supportFragmentManager\n val transaction = fm.beginTransaction()\n transaction.replace(android.R.id.content, createFragment())\n .commit()\n }\n }\n \n override fun beforeActivityLaunched() {\n super.beforeActivityLaunched()\n val application = InstrumentationRegistry.getInstrumentation()\n .targetContext.applicationContext as KoinTestApp\n application.injectModule(getModule())\n }\n\n protected abstract fun createFragment(): F\n \n protected abstract fun getModule(): Module\n \n fun launch() {\n launchActivity(Intent())\n }\n}\n\nfun <F: Fragment> createRule(fragment: F, module: Module): FragmentTestRule<F> = \n object: FragmentTestRule<F>() {\n override fun createFragment(): F = fragment\n\n override fun getModule(): Module = module\n }I am using default Android FragmentActivity to host fragment under test. So we need to mention this activity in the manifest. For that purpose I created instance of AndroidManifest inside debug variant in my app module:
<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<manifest\n xmlns:android=\"http://schemas.android.com/apk/res/android\"\n package=\"com.github.olegosipenko.kointestsample\">\n <application>\n <activity\n android:theme=\"@style/AppTheme\"\n android:name=\"androidx.fragment.app.FragmentActivity\"/>\n </application>\n</manifest>Finally, our test class could look like this:
\n@RunWith(AndroidJUnit4ClassRunner::class)\nclass EmailLoginFragmentTest {\n private val fragmentViewModel: EmailLoginFragmentViewModel = mockk(relaxed = true)\n private val fragment = EmailLoginFragment()\n\n @get:Rule\n val fragmentRule = createRule(fragment, module {\n single(override = true) {\n fragmentViewModel\n }\n })\n\n @Test\n fun testBasicInvocation() {\n onScreen<EmailLoginForm> {\n emailField { typeText(EMAIL) }\n passwordField { typeText(PASSWORD) }\n loginButton.click()\n verify {\n fragmentViewModel.loginWithCredentials(EMAIL, PASSWORD)\n }\n }\n }\n\n class EmailLoginForm: Screen<EmailLoginForm>() {\n val emailField = KEditText { withId(R.id.textFieldEmail) }\n val passwordField = KEditText { withId(R.id.textFieldPassword) }\n val loginButton = KButton { withId(R.id.buttonLogin) }\n }\n}\n\nprivate const val EMAIL = \"some@email.com\"\nprivate const val PASSWORD = \"password\"Here we are using Kakao, it’s a nice tool to simplify working with Espresso tests. It provides implementation of Page Object pattern and allows you to abstract interactions with your UI behind the abstract Screen objects. Using Kakao you can improve maintainability of your tests, so if you are not using it yet, give it a try. Also we are using Mockk for mocking, which uses all the power Kotlin gives us.
\nThat’s how with Koin, Kakao and Mockk you could easily test your fragments in isolation, making your life easier.
\nYou can check the source code for the sample here.
","fields":{"slug":"/testing-isolated-fragments-with-koin/","tags":["android","koin","kakao","mockk","espresso","android fragments"]}}}]}},"pageContext":{"slug":"/tags/mockk","tag":"mockk","categories":["Architecture","Coding","DevOps","Engineering","ProjectManagement","QA","Social","TechRadar"]}}