Actually I think that is a potential advantages of using JSR330. A test written with standard @Inject could benefit from additional JSR330-compatible DI frameworks. Potentially Dagger would fail at the moment for such tests but I think that would be an issue with Dagger. For example Dagger could provides its custom test runner in which is injects the Android test objects plus additonal Dagger managed objects.
2014-07-07 17:37 GMT+02:00 Jake Wharton <[email protected]>: > The problem with using JSR330 annotations is that any JSR330-compatible DI > framework embedded in the app (e.g., Dagger) is going to want to do things > with that code. Since Dagger is an annotation processor, it might fail your > test compilation because it can't determine from where these dependencies > are fulfilled. > > > On Thu, Jul 3, 2014 at 12:24 PM, vogella <[email protected]> wrote: > >> Hi, >> >> [this might the wrong group to post to, if that is the case point me into >> the correct direction for feedback to new Android testing framework.] >> >> I had a look at the prototype implementation of the new testing framework >> and it looks like the new approach uses dependency injections with specific >> annotations per type. >> >> >> https://android.googlesource.com/platform/frameworks/testing/+/e514756957cb44d88ceab42c53ef321e76e1368b/androidtestlib/src/com/android/test >> >> The following seems to be the plan to write a test with DI. >> >> --------------- >> >> public class MyJUnit4Test { >> >> @InjectInstrumentation >> public Instrumentation mInstrumentation; >> >> @InjectContext >> public Context mContext; >> >> @Test >> public void testCheck_Preconditions() { >> assertNotNull("mInstrumentation cannot be null", mInstrumentation); >> assertNotNull("mContext cannot be null", mContext); >> } >> } >> >> ------ >> I would suggest to change the approach to use the @Inject annotation from >> JSR330 and have a pre-filled data structure with the object which can be >> injected. This approach is for example used the Eclipse DI engine which >> uses the class name as key for the DI. >> >> >> public class MyJUnit4Test { >> >> @Inject >> public Instrumentation mInstrumentation; >> >> @Inject >> public Context mContext; >> >> @Test >> public void testCheck_Preconditions() { >> assertNotNull("mInstrumentation cannot be null", mInstrumentation); >> assertNotNull("mContext cannot be null", mContext); >> } >> } >> >> JSR330 also allows to specify the key, e.g., @Inject @Named("key1"): >> >> The advantage of this approach is IMHO is that you don't need new >> annotations in case you want to support more types to inject. The data >> structure Eclipse uses is basically (an enhanced) Map. >> >> Best regards, Lars >> >> P.S. >> >> JSR allows also to use additional qualifier The advantage of this >> approach is that the DI can be extended. For example you could allow to >> inject views for the test. >> >> @Inject @View @Named("myid") TextView view; >> >> -- >> You received this message because you are subscribed to the Google Groups >> "adt-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "adt-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/adt-dev/_k93a57NHF0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
