Feedback to the redesign of the Android testing framework

[vogella]

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;

[Jake Wharton]

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.

--
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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lars Vogel]

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.

--
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 adt-dev+u...@googlegroups.com.