Or application, or parent fragment. This fragment itself can’t inject it alone.

@w_bianrytree I'm following https://github.com/android/architecture-samples/tree/dagger-android And they don't either implement

HasAndroidInjector

That's why im confused, I'll try and add it somewhere

https://github.com/Nikola-Milovic/QuoteAppMvvm/blob/master/app/src/main/AndroidManifest.xml#L11 add

android:name="YourApplication"

should work

@czuckie i will write tests, main goal of this app is to practice DI,Mvvm and tests, but I am not as experienced in writing them. So i wanted to at least see my app work and do something and afterwords test everything that the user might do

And I 100% know that test driven dev is smarter but i plan to do that on my next app (write something and test it immediately)

there are a few approaches you can take- one that is easier to do is black (grey) box testing, where you use something like Espresso to spin up your application and then simulate a user clicking through it

for that to work well, you’d need a way to swap out something like the

QuoteRemoteDataSource

to do that, you’d need some kind of interface that represents what that is, and then you’d provide a test double implementation for it in your test (a mock)

so if you imagine your application as something you plug things into (your dependencies) you’ll be plugging in things that are more convenient for your tests when you are making sure the core of the application works

e.g. it’s a ballache to simulate a network timeout in a test, so you allow your interface to communicate such things in a more friendly way and then have your test double simulate a timeout, so that you can prove your application handles it in a correct way

looking at the

QuoteRemoteDataSource

, it might be that you actually want to mock

QuoteDataSource

instead

finding the right level to test at can be challenging, but if you treat your tests as you would production code (as you should, following rules you’d typically follow such as DRY etc) then if you change your level of testing, your tests shouldn’t have to change too much

I feel like I should clarify that what I’m saying isn’t something that’s carved in stone and an accepted best practice, but it’s something that’s helped me in the past deliver projects that I have confidence in. Having a suite of tests I can execute (even if they take 20 minutes) that gives me confidence that the application is working correctly, is something that I value highly. After being subject to multiple weeks of regression testing on other apps, being able to cut that time, allowing testers to focus on manual exploratory testing, i.e. what humans are good at, it hasn’t made me look back at the dark times