Hi, Does anyone here have experience or relevant r...

# dagger

[Amrita Chaturvedi]

Hi, Does anyone here have experience or relevant resources for mocking dagger related dependencies while unit testing in a multi-module clean architecture-based project? Kinda stuck with it here. 😅

[allan.conda]

What are you stuck with?

[Amrita Chaturvedi]

So I have created a testing app component, but I am unable to inject the classes in my test file.

[allan.conda]

what kind of test are you writing?

[Amrita Chaturvedi]

I am trying to test the ViewModels

[allan.conda]

For unit tests just construct the class in test manually.
See the last section here:
https://dagger.dev/dev-guide/testing.html

[Amrita Chaturvedi]

But I have a lot of dependencies, it will be difficult to manually create each of them.

[allan.conda]

Ok, I recommend read the whole article instead of just the last section.

[allan.conda]

It’s more difficult to write the dagger setup. You have to write tons of fakes, and mocks, anyway, if you want to test the ViewModel

[allan.conda]

And if you’re using Hilt, JVM tests aren’t supported yet

[Amrita Chaturvedi]

I was actually following the Option 2 that is mentioned there, but despite the dependency graph for Test App Component was generated, it couldn’t be injected.
I am not using Hilt, Just dagger android.

[allan.conda]

Hmm, you mention multi-module project, are you trying to inject fakes or other shared test classes (like test data) from another module, or just using plain mockito?

[allan.conda]

Test classes can’t be shared across modules normally

[Amrita Chaturvedi]

Not trying to fake other test classes as of now.

[trevjones]

So I don't know why its not in the docs or not recommended or w/e but I usually just do a standalone component for a specific test, works great with dagger android because a subcomponent implementation is specific to the enclosing component. plus then the graph validation is only on the parts of the graph you need for the test.

@Component(modules = [WhateverYouWantOrNeedModule::class])
interface TheTestComponent {
  val theViewModelToTest: SomeViewModel
  val somethingYouCheckToValidateOrConfigure: SomethingViewModelDependsOn
}

[trevjones]

i use a similar pattern for UI tests too. works great with the activity or fragment scenario rules so you can validate an entire view stack in isolation with faked network calls etc...

[trevjones]

if you are using just plain jar modules you can also use the test fixtures plugin and have your library module also provide fake versions of shared interfaces for things like data loading and such. then you are able to hopefully keep things like mockito out of your tests.

[Jeremy]

Generally you shouldn't need to do anything w/ dagger/di in your unit tests, thats the point of DI

[Jeremy]

If its espresso end to end test you can provide an alternate component in the relevant src variant dir and provide fakes for certain things like repository

[Jeremy]

If having trouble w/ testing due to "a lot of dependencies" might want to review classes to ensure seperation of concerns and/or use interfaces for the dependencies

[Amrita Chaturvedi]

It took me a while, but I finally understood.
Thank you! 🙌