Il processo si arresta in modo anomalo durante la creazione dell'iniettore RoboGuice, se è presente un'istanza derisa in qualsiasi modulo

85

Ho un problema con l'utilizzo dei framework RoboGuice e AndroidMock nei test unitari. Ho creato un semplice progetto per mostrare il mio problema. Qui creo un'istanza derisa e la registro in RoboGuice. Ma il processo va in crash tra i metodi "setUp ()" e "test01 ()". Come immagino, in realtà il processo si arresta in modo anomalo quando viene creato l'iniettore, se qualsiasi modulo ha un'istanza derisa all'interno.

Se sostituisco l'istanza derisa con un'istanza di una classe che implementa l'interfaccia, allora tutto funziona correttamente.

Qualcuno sa come risolvere questo problema?

Ecco il mio codice di prova:

public class testInjectMock extends RoboUnitTestCase<MyApplication> {
    protected void setUp() throws Exception {
        InterfaceToMock instance = AndroidMock.createNiceMock(InterfaceToMock.class);           AndroidMock.expect(instance.SimpleMethod()).andStubReturn("Hello!");            
        MyModule myMockModule = new MyModule();
        myMockModule.setMockedInstance(instance);//Comment this string to get into the test01() method          
        MyApplication.setMyModule(myMockModule);
        super.setUp();
    }
    public void test01() {
        //It never comes here
    }
}

Codice sorgente del modulo:

public class MyModule extends AbstractAndroidModule {
        protected InterfaceToMock mockedInstance;
        public void setMockedInstance(InterfaceToMock mockedInstance) {
            this.mockedInstance = mockedInstance;
        }
        @Override
        protected void configure() {
            if(mockedInstance != null)
                bind(InterfaceToMock.class).toInstance(mockedInstance);
        }
    }

L'output di logcat:

05-23 16:17:07.135: INFO/DEBUG(27): Build fingerprint: 'generic/sdk/generic/:2.1-update1/ECLAIR/35983:eng/test-keys'
05-23 16:17:07.135: INFO/DEBUG(27): pid: 2025, tid: 2031  >>> InjectMock.test <<<
05-23 16:17:07.145: INFO/DEBUG(27): signal 11 (SIGSEGV), fault addr 00000000
05-23 16:17:07.155: INFO/DEBUG(27):  r0 0011b218  r1 43d1caa0  r2 00000000  r3 00000000
05-23 16:17:07.155: INFO/DEBUG(27):  r4 43d1caa0  r5 0011b218  r6 451c0e30  r7 4000a958
05-23 16:17:07.155: INFO/DEBUG(27):  r8 ad00f380  r9 00138de0  10 426bda34  fp 00138de0
05-23 16:17:07.155: INFO/DEBUG(27):  ip 00000002  sp 451c0dc0  lr ad05ad1d  pc ad05a804  cpsr 00000030
05-23 16:17:07.295: INFO/DEBUG(27):          #00  pc 0005a804  /system/lib/libdvm.so
05-23 16:17:07.305: INFO/DEBUG(27):          #01  pc 0005ad18  /system/lib/libdvm.so
05-23 16:17:07.305: INFO/DEBUG(27):          #02  pc 00054a4a  /system/lib/libdvm.so
05-23 16:17:07.315: INFO/DEBUG(27):          #03  pc 00013f58  /system/lib/libdvm.so
05-23 16:17:07.325: INFO/DEBUG(27):          #04  pc 00019888  /system/lib/libdvm.so
05-23 16:17:07.335: INFO/DEBUG(27):          #05  pc 00018d5c  /system/lib/libdvm.so
05-23 16:17:07.335: INFO/DEBUG(27):          #06  pc 0004d6d0  /system/lib/libdvm.so
05-23 16:17:07.345: INFO/DEBUG(27):          #07  pc 0004d702  /system/lib/libdvm.so
05-23 16:17:07.355: INFO/DEBUG(27):          #08  pc 00041c78  /system/lib/libdvm.so
05-23 16:17:07.365: INFO/DEBUG(27):          #09  pc 00010000  /system/lib/libc.so
05-23 16:17:07.365: INFO/DEBUG(27):          #10  pc 0000fad4  /system/lib/libc.so
05-23 16:17:07.375: INFO/DEBUG(27): code around pc:
05-23 16:17:07.385: INFO/DEBUG(27): ad05a7f4 ffff5ae0 fffe57c4 6801b5f8 6a8b1c05 
05-23 16:17:07.385: INFO/DEBUG(27): ad05a804 1c30681e ff5ef7ff 28001c04 6840d018 
05-23 16:17:07.395: INFO/DEBUG(27): ad05a814 d0152800 37101c27 d0112f00 f7ff1c28 
05-23 16:17:07.395: INFO/DEBUG(27): code around lr:
05-23 16:17:07.405: INFO/DEBUG(27): ad05ad0c f7ff1c20 bd10ff7b 6804b510 fd70f7ff 
05-23 16:17:07.405: INFO/DEBUG(27): ad05ad1c 28001c01 f7ffd102 e002f859 f7ff1c20 
05-23 16:17:07.415: INFO/DEBUG(27): ad05ad2c bd10ff6d 4c24b5f0 1c0d1c06 48236a81 
05-23 16:17:07.425: INFO/DEBUG(27): stack:
05-23 16:17:07.425: INFO/DEBUG(27):     451c0d80  43d20870  /dev/ashmem/mspace/dalvik-heap/2 (deleted)
05-23 16:17:07.425: INFO/DEBUG(27):     451c0d84  00000354  
05-23 16:17:07.425: INFO/DEBUG(27):     451c0d88  00000022  
05-23 16:17:07.425: INFO/DEBUG(27):     451c0d8c  ad043693  /system/lib/libdvm.so
05-23 16:17:07.425: INFO/DEBUG(27):     451c0d90  ad07ff50  /system/lib/libdvm.so
05-23 16:17:07.425: INFO/DEBUG(27):     451c0d94  00000024  
05-23 16:17:07.425: INFO/DEBUG(27):     451c0d98  00000354  
05-23 16:17:07.425: INFO/DEBUG(27):     451c0d9c  ad0170ac  /system/lib/libdvm.so
05-23 16:17:07.425: INFO/DEBUG(27):     451c0da0  00000000  
05-23 16:17:07.435: INFO/DEBUG(27):     451c0da4  afe0f2c0  /system/lib/libc.so
05-23 16:17:07.435: INFO/DEBUG(27):     451c0da8  ad080c00  /system/lib/libdvm.so
05-23 16:17:07.435: INFO/DEBUG(27):     451c0dac  00000002  
05-23 16:17:07.435: INFO/DEBUG(27):     451c0db0  00000354  
05-23 16:17:07.445: INFO/DEBUG(27):     451c0db4  43d20870  /dev/ashmem/mspace/dalvik-heap/2 (deleted)
05-23 16:17:07.445: INFO/DEBUG(27):     451c0db8  df002777  
05-23 16:17:07.455: INFO/DEBUG(27):     451c0dbc  e3a070ad  
05-23 16:17:07.455: INFO/DEBUG(27): #00 451c0dc0  00000000  
05-23 16:17:07.455: INFO/DEBUG(27):     451c0dc4  43d1caa0  /dev/ashmem/mspace/dalvik-heap/2 (deleted)
05-23 16:17:07.455: INFO/DEBUG(27):     451c0dc8  451c0e38  
05-23 16:17:07.455: INFO/DEBUG(27):     451c0dcc  451c0e30  
05-23 16:17:07.455: INFO/DEBUG(27):     451c0dd0  4000a958  /dev/ashmem/mspace/dalvik-heap/zygote/0 (deleted)
05-23 16:17:07.455: INFO/DEBUG(27):     451c0dd4  ad05ad1d  /system/lib/libdvm.so
05-23 16:17:07.465: INFO/DEBUG(27): #01 451c0dd8  417a0b5c  /data/dalvik-cache/system@framework@core.jar@classes.dex
05-23 16:17:07.475: INFO/DEBUG(27):     451c0ddc  ad054a4f  /system/lib/libdvm.so
java  android  eclipse  roboguice 
— Andrey
fonte
1
Informazioni aggiuntive: è possibile creare iniettore con un'istanza simulata in qualsiasi modulo. Ho creato con successo l'iniettore nel metodo "test01 ()". Ma se l'iniettore viene creato da RoboUnitTestCase, l'app va in crash.
— Andrey
16
La fonte RoboUnitTestCase code.google.com/p/roboguice/source/browse/roboguice/src/main/... dice "Assicurarsi di utilizzare una delle @ * annotazioni di prova e iniziare il nome del vostro testcase con 'test'" ma il vostro programma di installazione non è annotato @Beforee il tuo test non è annotato @Test...
— Paul D'Ambra
2
Sembra che non sia direttamente un problema java ( signal 11 (SIGSEGV), fault addr 0000000). Potresti provare con un'altra versione del firmware (emulatore o dispositivo)?
— Pierre-Henri
Potresti darci la definizione dell'interfaccia InterfaceToMock, in modo da poter riprodurre l'esatto comportamento di AndroidMock.createNiceMock.
— Remco
Se uno di A fosse buono per te, potresti accettarlo? Q è ancora aperto.
— Glen Best

Risposte:

5

Sfortunatamente, se c'è un problema con i passaggi di configurazione per RoboGuice e test di unità, puoi ricevere questo tipo di errore. Nessuna risposta breve magica, ma piuttosto una serie di passaggi da seguire esattamente.

A proposito, stai usando RoboGuice 1.1 - AbstractAndroidModule e RoboUnitTest non esistono più in RoboGuice 2.0. RoboGuice 1.1 è deprecato, quindi la migliore soluzione complessiva è passare alla versione più recente secondo queste istruzioni Aggiornamento alla 2.0 .

Tuttavia, nel caso in cui tu sia collegato a RoboGuice 1.1, ecco alcuni passaggi da seguire:

  • Non avere file di codice / build generati incoerenti dopo il refactoring / la modifica dei nomi dei pacchetti, ecc. Elimina il codice generato, esegui un Clean & Build, persino ricrea un nuovo progetto e copia i file sorgente in.
  • Avere il codice della tua app in un progetto (dipendente da RoboGuice, indipendente da Instrumentation / RoboUnitTestCase / AndroidMock). Il tuo progetto di codice dell'app ha in lib: guice-2.0-no_aop.jar e roboguice-1.1.2.jar.
  • Avere il codice di unit test in un altro progetto che fa riferimento ad esso (RoboGuice indipendente, Instrumentation / RoboUnitTestCase / AndroidMock indipendente). Istruzioni qui prima di iniziare . Il progetto del codice di test ha in lib: AndroidMockGenerator.jar.

  • Nel progetto della tua app, le tue classi App + Module hanno un aspetto simile a questo:

    package com.mypackage;

import android.app.Instrumentation;
import android.content.Context;

public class MyApplication extends roboguice.application.RoboApplication {

static MyModule myModule;    

// this constructor usually called by app
public MyApplication(Context context) {
    super();
    attachBaseContext(context);
}
// This constructor called by unit tests.  This is unfortunately small amount of 
// 'abstraction leakage' of unit test needs into app code.
public MyApplication(Instrumentation instrumentation) {
    super();
    attachBaseContext(instrumentation.getContext());
}    
public static void setModule(MyModule module) {
    MyApplication.myModule = module;
}   
public static MyModule getModule() {
    return MyApplication.myModule;
}   
}

    E

    package com.mypackage;

public class MyModule extends roboguice.config.AbstractAndroidModule {
// this will be injected
protected UsefulObject myUsefulInstance;    

public void setUsefulObject(UsefulObject usefulInstance) {
    this.myUsefulInstance = usefulInstance;
}    
public UsefulObject getUsefulObject() {
    return this.myUsefulInstance;
}    

@Override
protected void configure() {
    bind(UsefulObject.class).toInstance(myUsefulInstance);
}

    }

  • Nel progetto di test, la classe del test case ha un aspetto simile a questo:

    import android.test.suitebuilder.annotation.LargeTest;    
import com.mypackage.MyApplication;    
import com.mypackage.MyModule;    
import com.mypackage.UsefulObject;    
 //import com.mypackage.UsefulObjectSimpleImplementation;    
import android.test.suitebuilder.annotation.MediumTest;    
import android.test.suitebuilder.annotation.SmallTest;    
import com.google.android.testing.mocking.AndroidMock;    
import roboguice.test.RoboUnitTestCase;

public class TestMyModule extends RoboUnitTestCase<MyApplication> {

@Override
protected void setUp() throws Exception {
    UsefulObject instance = // new UsefulObjectSimpleImplementation(); 
                            AndroidMock.createNiceMock(UsefulObject.class);           
    MyModule mockModule = new MyModule();
    mockModule.setUsefulObject(instance);
    MyApplication.setModule(mockModule);
    super.setUp();
}

// Make sure you use one of the @*Test annotations AND begin
// your testcase's name with "test"
@MediumTest
public void test01() {
    AndroidMock.expect(MyApplication.getModule().getUsefulObject().
         simpleMethod()).andStubReturn("Hello!");
}

    }

  • Assicurati che per il progetto di test, il file AndroidManifest.xml abbia la seguente voce:

   <instrumentation android:name="android.test.InstrumentationTestRunner"
     android:targetPackage="com.mypackage"
     android:label="Tests for com.mypackage"/>
  • Prima di eseguire il test, assicurati che l'emulatore sia avviato e funzioni correttamente, eseguendo prima un'app "Hello World" diversa e semplice. Quando ha successo, esegui la tua app. Infine, esegui il tuo progetto di test.

Dovrebbe funzionare dopo questo. Buona fortuna e fammi sapere!

— Glen Best
fonte
0

Purtroppo questo è un bug in Android stesso. Vedi la segnalazione di bug qui . La VM si arresta in modo anomalo quando tenta di cercare annotazioni su un proxy , che è ciò che AndroidMock utilizza quando deride un'interfaccia .

La soluzione è creare in istanza una classe che implementa l'interfaccia, come hai sottolineato nella tua domanda. Potresti provare a creare una classe astratta pura che implementa l'interfaccia senza implementare alcun metodo, quindi utilizzare AndroidMock per deridere quella classe invece dell'interfaccia. Ciò dovrebbe evitare la creazione di un proxy.

— svattom
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.