AssertionFailedError w ApplicationTestCase.createApplication() w nowszych wersjach Androida przy użyciu MockContext

Question

Piszę Android ApplicationTestCase (przykład TemperatureConverterApplicationTests znaleźć w Android Application Testing Guide Diego T. Milano na stronie 171). Przykład został napisany dla systemu Android 2.3 i nie wydaje się działać na systemie Android 4. Nie musisz znać książki, aby zrozumieć problem, ponieważ go uprościliśmy.

To działa prawidłowo z Android 2.3.3 (API 10):

setContext(new MockContext()); 
createApplication(); 

[Aby być precyzyjnym UnsupportedOperationException jest generowany, ponieważ getPackageName() nie jest realizowany. Ale jest to normalne i można je rozwiązać, używając podklasy MockContext(), która implementuje metody getPackageName() i getSharedPreferences(). Nie ma to znaczenia, ponieważ problem nadal występuje nawet po wykonaniu tej czynności.]

Problem polega na tym, że z Android 4.1.2 (API 16) to nie działa. Otrzymuję AssertionFailedError, że poprzez niektóre debugowania okazało się, ze względu na wyjątek ClassCastException wyrzucane na linii 100 z ApplicationTestCase.

mApplication = (T) Instrumentation.newApplication(mApplicationClass, getContext()); 

ClassCastException komunikat:

java.lang.ClassCastException: android.test.mock.MockContext cannot be cast to android.app.ContextImpl 

sugestie dlaczego tak się dzieje i jak można go uniknąć?

EDIT: Podobne pytanie: Android ApplicationTestCase using a MockContext

Answer 1

Sposób Instrumentation.newApplication() zwróci obiekt Application. Próbujesz rzucić go do tego, co jest T. Jeśli T nie jest superklasą lub podkategorią Application, otrzymasz ClassCastException. W Javie można rzutować obiekt tylko na coś, co jest superklasą lub podklasą tego obiektu. Jeśli tak nie jest, zostanie zgłoszony wyjątek.

NA PRZYKŁAD:

Object x = new Integer(0); 
System.out.println((String)x); 

Ten rzuci ClassCastException w drugiej linii, bo próbujesz rzucić x (an Integer Object) do String. Ponieważ String i Integer nie są podrzędnymi ani super-klasami.

Answer 2

Dostaję też to zachowanie. Pracowałem nad tym rozszerzeniem ContextWrapper:

public class RenamingMockContext extends RenamingDelegatingContext 
{ 
    private static final String PREFIX = "test."; 

    public RenamingMockContext(Context context) 
    { 
     super(new ContextWrapper(context), PREFIX); 
    } 

    @Override 
    public String getPackageName() 
    { 
     return PREFIX + super.getPackageName(); 
    } 
}