We have an Android app that is using compose for the view layer and we are using Kodein for all of our dependency injections.
I have a BaseApplication class which is DIAware:
class BaseApplication : Application(), DIAware {
override val di: DI = DI.lazy {
import(modules) // modules defined in respective packages
}
}
I also have a MainActivity and a nav graph to manage navigation between the various composables.
Problem:
How can I properly override these modules in my instrumented tests for MainActivity?
#RunWith(AndroidJUnit4::class)
class MainActivityTest {
#get:Rule
val composeTestRule = createAndroidComposeRule<MainActivity>()
val moduleOverrides = DI.Module(allowSilentOverride = true) {
// add bindings for fakes w/ allowOverride = true
}
#Before
fun setup() {
val application =
ApplicationProvider.getApplicationContext() as BaseApplication
// how can I override the BaseApplication modules for my test?
}
}
I cant seem to find any clear language on the matter and feel like I am missing something very obvious. Any help would be very much appreciated.
There are several ways to achieve that. The general approach is to override the actual modules like
val someParrentKodeinModule...
val mockModule = Kodein {
extend(someParrentKodeinModule, allowOverride = true)
bind<Foo>(overrides = true) with provider { Foo2() }
}
or
val kodein = Kodein {
/* ... */
import(testsModule, allowOverride = true)
}
where testsModule is some module that already defines all the needed mock components that will be overridden in the main one.
Your approach is also good. The key point is to replace your DI with the needed one - this can be done making the DI in your app - var instead of val and assigning new value to it. But you will have to drop DIAware
class BaseApplication : Application() {
var di: DI = DI.lazy {
import(modules) // modules defined in respective packages
}
}
#Before
fun setup() {
val application =
ApplicationProvider.getApplicationContext() as BaseApplication
application.di = moduleOverrides
}
Something like that.
And generally using single DI for the app inside the App class is not recommended. Use specialized modules for each component of the app you want to test
Related
So I want to test my jetpack compose project. It's easy enough running an instrument test following [these instructions]1 on android dev site, but when you add #HiltViewModel injection into the combination things get complicated.
I'm trying to test a pretty simple compose screen with a ViewModel that has an #Inject constructor.
The screen itself looks like this:
#Composable
fun LandingScreen() {
val loginViewModel: LoginViewModel = viewModel()
MyTheme {
Surface(color = MaterialTheme.colors.background) {
val user by loginViewModel.user.observeAsState()
if (user != null) {
MainScreen()
} else {
LoginScreen(loginViewModel)
}
}
}
}
and this is the view model:
#HiltViewModel
class LoginViewModel #Inject constructor(private val userService: UserService) : ViewModel() {
val user = userService.loggedInUser.asLiveData()
}
User service is of course backed by a room database and the loggedInUser property returns a Flow.
Things work as expected on standard run but when trying to run it in an instrument test it can't inject the view model.
#HiltAndroidTest
class LandingScreenTest {
#get:Rule
var hiltRule = HiltAndroidRule(this)
#get:Rule
val composeTestRule = createComposeRule()
#Inject
lateinit var loginViewModel: LoginViewModel
#Before
fun init() {
hiltRule.inject()
}
#Test
fun MyTest() {
composeTestRule.setContent {
MyTheme {
LandingScreen()
}
}
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
}
}
Injection of an #HiltViewModel class is prohibited since it does not
create a ViewModel instance correctly. Access the ViewModel via the
Android APIs (e.g. ViewModelProvider) instead. Injected ViewModel:
com.example.viewmodels.LoginViewModel
How do you make that work with the ViewModelProvider instead of the #HiltViewModel?
Hilt needs an entry point to inject fields. In this case that would probably be an Activity annotated with #AndroidEntryPoint. You can use your MainActivity for that, but that would mean that you would then have to add code to every test to navigate to the desired screen which could be tedious depending on the size of your app, and is not feasible if your project is multimodule and your current Test file does not have access to MainActivity. Instead, you could create a separate dummy Activity whose sole purpose is to host your composable (in this case LoginScreen) and annotate it with #AndroidEntryPoint. Make sure to put it into a debug directory so it's not shipped with the project. Then you can use createAndroidComposeRule<Activity>() to reference that composable. You dont need to inject the ViewModel directly so get rid of that line too.
In the end your Test File should look like this:
#HiltAndroidTest
class LandingScreenTest {
#get:Rule(order = 0)
val hiltRule = HiltAndroidRule(this)
#get:Rule(order = 1)
val composeRule = createAndroidComposeRule<LoginTestActivity>()
#Before
fun init() {
hiltRule.inject()
}
#Test
fun MyTest() {
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
}
}
And your your dummy activity can look like this:
#AndroidEntryPoint
class LoginTestActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
LoginScreen()
}
}
}
And the debug directory would look like this:debug directory with dummy activity
Yes the debug directory has its own manifest and that is where you should add the dummy activity. set exported to false.
Try to do something like this:
#HiltAndroidTest
class LandingScreenTest {
#get:Rule
var hiltRule = HiltAndroidRule(this)
#get:Rule
val composeTestRule = createComposeRule()
// Remove this line #Inject
lateinit var loginViewModel: LoginViewModel
#Before
fun init() {
hiltRule.inject()
}
#Test
fun MyTest() {
composeTestRule.setContent {
loginViewModel= hiltViewModel() // Add this line
MyTheme {
LandingScreen()
}
}
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
}
}
You must annotate any UI test that uses Hilt with #HiltAndroidTest. This annotation is responsible for generating the Hilt components for each test.
https://developer.android.com/training/dependency-injection/hilt-testing
I have a class for which I have written unit tests. The class injects 2 other classes via the constructor. However due to cyclic dependency issues, I had to inject one of the other dependencies via by inject().
My class looks as the follows:
class AuthUseCase(
private val accessTokenUseCase: AccessTokenUseCase,
private val refreshTokenRepo: RefreshTokenRepo
) : KoinComponent {
val notificationService: NotificationService by inject()
fun getSyncedAccessToken(loginResult: LoginResult): Token? {
return when (loginResult) {
is LoginResult.Success -> {
accessTokenUseCase.storeRefreshToken(loginResult.accessToken)
notificationService.init()
loginResult.accessToken.accessToken
}
is LoginResult.Failure -> {
null
}
}
}
}
I want to test if notificationService.init was fired or not in my test.
Normally it would be as simple as
verify(notificationService).init()
However I cannot understand how to mock this class. Any help would be highly appreciated.
Thanks to #Mariuz and through this post:
https://github.com/InsertKoinIO/koin/issues/197#issuecomment-429768448
The trick is to start an empty Koin container. And load mocked module in the test.
#Test
fun testGetValidAccessTokenIfInvalidAccessTokenIsPassed() {
notificationService = mock()
startKoin { }
loadKoinModules(module {
single {
notificationService
}
})
verify(notificationService).init()
}
One of my classes has a dependency of type Context. Before adding Koin to my project, I initialized this with a hard dependency on my Application class:
class ProfileRepository(
private var _context: Context? = null,
private var _profileRestService: IProfileRestService? = null
) : IProfileRepository {
init {
if (_context == null) {
_context = MyApplication.getInstance().applicationContext
}
}
Now, I want to use Koin to inject this dependency. This is how I've defined the module:
object AppModule {
#JvmField
val appModule = module {
single<IProfileRestService> { ProfileRestService() }
single<IProfileRepository> { ProfileRepository(androidContext(), get()) }
}
}
I'm starting Koin in the onCreate method of my Application class (which is written in Java):
startKoin(singletonList(AppModule.appModule));
I want to test this class with an instrumented test and not a unit test because I want to use the real context and not a mock. This is my test:
#RunWith(AndroidJUnit4::class)
class MyTest : KoinTest {
private val _profileRepository by inject<IProfileRepository>()
#Test
fun testSomething() {
assertNotNull(_profileRepository)
}
The test is failing with an exception:
org.koin.error.BeanInstanceCreationException: Can't create definition for 'Single [name='IProfileRepository',class='com.my.app.data.profile.IProfileRepository']' due to error :
No compatible definition found. Check your module definition
I can get it to work with a unit test if I mock the context like so:
class MyTest : KoinTest {
private val _profileRepository by inject<IProfileRepository>()
#Before
fun before() {
startKoin(listOf(AppModule.appModule)) with mock(Context::class.java)
}
#After
fun after() {
stopKoin()
}
#Test
fun testSomething() {
assertNotNull(_profileRepository)
}
How can I make it work as an instrumented test with a real context?
In place of (in Application):
startKoin(applicationContext, modules)
Use a mocked Context:
startKoin(modules) with (mock(Context::class.java))
From https://insert-koin.io/docs/1.0/documentation/koin-android/index.html#_starting_koin_with_android_context_from_elsewhere
Apparently there's no way to start Koin from a Java class and inject the application context. What that means is if one of your classes needs to get the context from the container, you must use org.koin.android.ext.android.startKoin instead of org.koin.java.standalone.KoinJavaStarter.startKoin.
Since my Application class is still written in Java, I created an object called KoinHelper with one method:
#JvmStatic
fun start(application: Application) {
application.startKoin(application, listOf(AppModule.appModule))
}
Then I called this from the onCreate method of my Application class:
KoinHelper.start(this);
Now, the instrumented test I posted in my original answer runs just fine.
Please see this issue on GitHub for more info.
Please check this section in the documentation. It says
if you need to start Koin from another Android class, you can use the
startKoin() function and provide your Android Context instance with
just like:
startKoin(androidContext, myAppModules)
So in your instrumentation test, you can pass a context while starting the Koin.
#Before
fun before() {
startKoin(InstrumentationRegistry.getContext(), listOf(AppModule.appModule))
}
Or if you want an application level context
#Before
fun before() {
startKoin(InstrumentationRegistry.getTargetContext(), listOf(AppModule.appModule))
}
The referenced documentation is for Version 1.0.1
In terms of getting the Application context in the instrumented test, you can use androidx.test.core.app.ApplicationProvider or InstrumentationRegistry.targetContext.applicationContext.
#Before
fun setUp() {
stopKoin()
loadKoinModules(testModule) with ApplicationProvider.getApplicationContext<Application>()
}
...where testModule uses androidApplication() to retrieve the Application context:
val testModule = module {
single {
ToDoDatabase.newInstance(
androidApplication(),
memoryOnly = true
)
}
single { ToDoRepository(get()) }
}
Note that my stopKoin() call is there because I was having difficulty overriding an existing module created by startKoin() in my custom Application subclass. ¯\_(ツ)_/¯
#Before
fun setUp() {
stopKoin()
startKoin {
androidContext(app) // for example ApplicationProvider.getApplicationContext<TestApplication>()
modules(module1, module2)
}
}
I'm currently writing some UI unit tests for a fragment, and one of these #Test is to see if a list of objects is correctly displayed, this is not an integration test, therefore I wish to mock the ViewModel.
The fragment's vars:
class FavoritesFragment : Fragment() {
private lateinit var adapter: FavoritesAdapter
private lateinit var viewModel: FavoritesViewModel
#Inject lateinit var viewModelFactory: FavoritesViewModelFactory
(...)
Here's the code:
#MediumTest
#RunWith(AndroidJUnit4::class)
class FavoritesFragmentTest {
#Rule #JvmField val activityRule = ActivityTestRule(TestFragmentActivity::class.java, true, true)
#Rule #JvmField val instantTaskExecutorRule = InstantTaskExecutorRule()
private val results = MutableLiveData<Resource<List<FavoriteView>>>()
private val viewModel = mock(FavoritesViewModel::class.java)
private lateinit var favoritesFragment: FavoritesFragment
#Before
fun setup() {
favoritesFragment = FavoritesFragment.newInstance()
activityRule.activity.addFragment(favoritesFragment)
`when`(viewModel.getFavourites()).thenReturn(results)
}
(...)
// This is the initial part of the test where I intend to push to the view
#Test
fun whenDataComesInItIsCorrectlyDisplayedOnTheList() {
val resultsList = TestFactoryFavoriteView.generateFavoriteViewList()
results.postValue(Resource.success(resultsList))
(...)
}
I was able to mock the ViewModel but of course, that's not the same ViewModel created inside the Fragment.
So my question really, has someone done this successfully or has some pointers/references that might help me out?
Also, I've tried looking into the google-samples but with no luck.
For reference, the project can be found here: https://github.com/JoaquimLey/transport-eta/
Within your test setup you'll need to provide a test version of the FavoritesViewModelFactory which is being injected in the Fragment.
You could do something like the following, where the Module will need to be added to your TestAppComponent:
#Module
object TestFavoritesViewModelModule {
val viewModelFactory: FavoritesViewModelFactory = mock()
#JvmStatic
#Provides
fun provideFavoritesViewModelFactory(): FavoritesViewModelFactory {
return viewModelFactory
}
}
You'd then be able to provide your Mock viewModel in the test.
fun setupViewModelFactory() {
whenever(TestFavoritesViewModelModule.viewModelFactory.create(FavoritesViewModel::class.java)).thenReturn(viewModel)
}
I have solved this problem using an extra object injected by Dagger, you can find the full example here: https://github.com/fabioCollini/ArchitectureComponentsDemo
In the fragment I am not using directly the ViewModelFactory, I have defined a custom factory defined as a Dagger singleton:
https://github.com/fabioCollini/ArchitectureComponentsDemo/blob/master/uisearch/src/main/java/it/codingjam/github/ui/search/SearchFragment.kt
Then in the test I replace using DaggerMock this custom factory using a factory that always returns a mock instead of the real viewModel:
https://github.com/fabioCollini/ArchitectureComponentsDemo/blob/master/uisearchTest/src/androidTest/java/it/codingjam/github/ui/repo/SearchFragmentTest.kt
Look like, you use kotlin and koin(1.0-beta).
It is my decision for mocking
#RunWith(AndroidJUnit4::class)
class DashboardFragmentTest : KoinTest {
#Rule
#JvmField
val activityRule = ActivityTestRule(SingleFragmentActivity::class.java, true, true)
#Rule
#JvmField
val executorRule = TaskExecutorWithIdlingResourceRule()
#Rule
#JvmField
val countingAppExecutors = CountingAppExecutorsRule()
private val testFragment = DashboardFragment()
private lateinit var dashboardViewModel: DashboardViewModel
private lateinit var router: Router
private val devicesSuccess = MutableLiveData<List<Device>>()
private val devicesFailure = MutableLiveData<String>()
#Before
fun setUp() {
dashboardViewModel = Mockito.mock(DashboardViewModel::class.java)
Mockito.`when`(dashboardViewModel.devicesSuccess).thenReturn(devicesSuccess)
Mockito.`when`(dashboardViewModel.devicesFailure).thenReturn(devicesFailure)
Mockito.`when`(dashboardViewModel.getDevices()).thenAnswer { _ -> Any() }
router = Mockito.mock(Router::class.java)
Mockito.`when`(router.loginActivity(activityRule.activity)).thenAnswer { _ -> Any() }
StandAloneContext.loadKoinModules(hsApp + hsViewModel + api + listOf(module {
single(override = true) { router }
factory(override = true) { dashboardViewModel } bind ViewModel::class
}))
activityRule.activity.setFragment(testFragment)
EspressoTestUtil.disableProgressBarAnimations(activityRule)
}
#After
fun tearDown() {
activityRule.finishActivity()
StandAloneContext.closeKoin()
}
#Test
fun devicesSuccess(){
val list = listOf(Device(deviceName = "name1Item"), Device(deviceName = "name2"), Device(deviceName = "name3"))
devicesSuccess.postValue(list)
onView(withId(R.id.rv_devices)).check(ViewAssertions.matches(ViewMatchers.isCompletelyDisplayed()))
onView(withId(R.id.rv_devices)).check(matches(hasDescendant(withText("name1Item"))))
onView(withId(R.id.rv_devices)).check(matches(hasDescendant(withText("name2"))))
onView(withId(R.id.rv_devices)).check(matches(hasDescendant(withText("name3"))))
}
#Test
fun devicesFailure(){
devicesFailure.postValue("error")
onView(withId(R.id.rv_devices)).check(ViewAssertions.matches(ViewMatchers.isCompletelyDisplayed()))
Mockito.verify(router, times(1)).loginActivity(testFragment.activity!!)
}
#Test
fun devicesCall() {
onView(withId(R.id.rv_devices)).check(ViewAssertions.matches(ViewMatchers.isCompletelyDisplayed()))
Mockito.verify(dashboardViewModel, Mockito.times(1)).getDevices()
}
}
In the example you provided, you are using mockito to return a mock for a specific instance of your view model, and not for every instance.
In order to make this work, you will have to have your fragment use the exact view model mock that you have created.
Most likely this would come from a store or a repository, so you could put your mock there? It really depends on how you setup the acquisition of the view model in your Fragments logic.
Recommendations:
1) Mock the data sources the view model is constructed from or
2) add a fragment.setViewModel() and Mark it as only for use in tests. This is a little ugly, but if you don't want to mock data sources, it is pretty easy this way.
One could easily mock a ViewModel and other objects without Dagger simply by:
Create a wrapper class that can re-route calls to the ViewModelProvider. Below is the production version of the wrapper class that simply passes the calls to the real ViewModelProvider which is passed in as a parameter.
class VMProviderInterceptorImpl : VMProviderInterceptor { override fun get(viewModelProvider: ViewModelProvider, x: Class<out ViewModel>): ViewModel {
return viewModelProvider.get(x)
}
}
Adding getters and setters for this wrapper object to the Application class.
In the Activity rule, before an activity is launched, swap out the real wrapper with a mocked wrapper that does not route the get ViewModel call to the real viewModelProvider and instead provides a mocked object.
I realize this is not as powerful as dagger but the simplicity is attractive.
I'm trying to make some tests and i need to replace the real dependency by a fake one by overriding it on KODEIN but it's not working and i don't know what i can do anymore.
Here is my dependency graph (I'm omitting others dependencies):
class Injector(private val context: Context) {
val dependencies = Kodein.lazy {
.
.
bind<RetrieveContacts>() with provider {
Log.i("RetrieveContacts","REAL")
RetrieveContactsInMemory()
}
.
.
}
}
Here is my application class:
class AppApplication : Application(), KodeinAware {
override val kodein by Injector(this).dependencies
}
Here is what i'm doing to override the dependency:
#RunWith(value = AndroidJUnit4::class)
class HomeActivityEmptyStateTest {
#get:Rule
var mActivityTestRule = ActivityTestRule<HomeActivity>(HomeActivity::class.java)
#Before
fun setup() {
val appApplication = InstrumentationRegistry.getInstrumentation().targetContext
val kodein by Kodein.lazy {
extend(appApplication.appKodein())
bind<RetrieveContacts>(overrides = true) with provider {
Log.i("RetrieveContacts","FAKE")
RetrieveEmptyContacts()
}
}
}
#Test
fun testWhenHasNoContent() {
...
}
}
I'm still seeing "RetrieveContacts REAL" instead of "RetrieveContacts FAKE" in console log
It seems like you forgot to allow overrides when extending in your test.
extend(appApplication.appKodein(), allowOverride = true)
This does not work since the parents definition will not be overridden. more info: https://kodein.org/Kodein-DI/?6.1/core#_overridden_access_from_parent
This is because Bar is bound to a singleton, the first access would
define the container used (parent or child). If the singleton were
initialized by child, then a subsequent access from parent would yeild
a Bar with a reference to a Foo2, which is not supposed to exist in
parent.