Add espresso example to demo swapping dependenices for espresso tests#742
Add espresso example to demo swapping dependenices for espresso tests#742kmdupr33 wants to merge 4 commits intogoogle:masterfrom
Conversation
| android:targetSdkVersion="24"/> | ||
|
|
||
| <application | ||
| android:label="Espresso Dagger" |
There was a problem hiding this comment.
Maybe just "Instrumentation Dagger"?
Espresso is a concrete library for Instrumentation UI tests which not everybody use and not only it does not matter for this sample but it's also just an implementation detail.
There was a problem hiding this comment.
I'm open to that. Depends on where folks want to go with this sample.
I imagined that we might eventually want to demo best practices for solving some espresso-specific problems with Dagger. For example, we might want to show how to setup modules and components so that you can inject dependencies that implement IdlingResource for a test build variant. Maybe that's a bad example, but if we want to show any espresso specific stuff, then maybe the name should stay.
| import dagger.example.android.espresso.main.ApiClient; | ||
|
|
||
| @Module | ||
| public class StubNetworkingModule { |
There was a problem hiding this comment.
Why redeclare module instead of extending and overriding only those @Provides methods that you need?
There was a problem hiding this comment.
Overriding modules is not recommended by the testing guide. https://google.github.io/dagger//testing.html
There was a problem hiding this comment.
That is an anti-pattern as it requires the real dependencies of that provider be available and it prevents adding test-only dependencies for the test version of the provider. Composing modules is much more powerful and is the recommended practice.
There was a problem hiding this comment.
True, but mostly overriding is completely fine while redeclaring requires either duplicating other @Provides methods or creating modules just for one dependency.
Obviously composition is preferred over inheritance, but there is cost to each decision.
Anyway, this seems covered pretty well in docs now so let's stick to "recommended" practice.
There was a problem hiding this comment.
bump. is this going to get merged?
|
@ronshapiro What needs to be done to get this example in? It would be nice to see this for people that would like to migrate to Bazel. |
6 participants
This addresses #571 and #564
Currently, it doesn't look like there's support for instrumentation tests with Bazel (see the commit message here, so as @ronshapiro suggested here, I'm not going to worry about that part. Moreover, the manifest merger doesn't appear to work as advertised, so there is some duplication between main and stubbed variant manifests.