Hey guys, I am having trouble with Dagger2 DI my fragments. I'm trying to use the googles dagger2 mv...

# android

[Nikola Milovic]

Hey guys, I am having trouble with Dagger2 DI my fragments. I'm trying to use the googles dagger2 mvvm architecture as a reference but it's not working. The solutions I found online are deprecated or i am uncertain how to use them. I am still learning DI and dagger so it's not perfect
Here's the error and the fragment that's causing it: https://hastebin.com/ipudoharef.m
Here's my DI: https://github.com/Nikola-Milovic/QuoteAppMvvm/tree/master/app/src/main/java/com/example/quoteappmvvm/di

[w_bianrytree]

your activity doesn’t have HasAndroidInjector implemented

[w_bianrytree]

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

[w_bianrytree]

https://github.com/google/dagger/blob/0dc6755ba970530811e223a5942a359f819fc071/java/dagger/android/AndroidInjection.java#L62

[czuckie]

it would be great to see some unit tests in there

[Nikola Milovic]

I know Chris, I wanted to launch the app first and then do some tests @czuckie

[Nikola Milovic]

@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

[w_bianrytree]

Well. I found the problem, your application is not assigned to manifest. Therefore your application doesn’t have HasAndroidInjector implemented

[w_bianrytree]

https://github.com/Nikola-Milovic/QuoteAppMvvm/blob/master/app/src/main/AndroidManifest.xml#L11
add android:name="YourApplication"
should work

[czuckie]

@Nikola Milovic you just might find you never end up getting around to writing your tests because there is always another feature to write first 😄. It’s best to write the tests first from that perspective, but as a learning exercise it’d be cool to see one test where you can swap out one of the modules for the purposes of test

[Nikola Milovic]

@w_bianrytree wow, that was it... thank you, i probably never would have done that

[Nikola Milovic]

@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

[Nikola Milovic]

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)

[w_bianrytree]

Well. I do believe TDD is debatable for Android development. Not always that great. I do love to write test for logical works instead of testing my activity or some uI.

[Nikola Milovic]

@w_bianrytree thank you very much! I would've struggled on this way longer than these 20 mins
@czuckie thank you as well

[rmyhal]

https://codelabs.developers.google.com/codelabs/android-dagger/index.html?index=..%2F..ads19#0
here is the codelab from the Google, how to use dagger

[Nikola Milovic]

@czuckie hey man, since i got my app to work somewhat, how would I go about testing it?
I tried some things on my own but i am quite lost on where to begin

https://github.com/Nikola-Milovic/QuoteAppMvvm

[czuckie]

wooo first of all, great for trying! let me have a quick look

[czuckie]

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

[czuckie]

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

[czuckie]

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)

[czuckie]

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

[czuckie]

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

[czuckie]

looking at the QuoteRemoteDataSource, it might be that you actually want to mock QuoteDataSource instead

[czuckie]

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

[czuckie]

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

[Nikola Milovic]

Thank you! I’ll look into everything and come back if i get really stuck