El proceso se bloquea durante la creación del inyector RoboGuice, si hay una instancia simulada en cualquier módulo

85

Tengo un problema con el uso de los marcos RoboGuice y AndroidMock en las pruebas unitarias. Creé un proyecto simple para mostrar mi problema. Aquí creo una instancia simulada y la registro en RoboGuice. Pero el proceso falla entre los métodos "setUp ()" y "test01 ()". Como supongo, en realidad el proceso se bloquea cuando se crea el inyector, si algún módulo tiene una instancia simulada en su interior.

Si reemplazo la instancia simulada con una instancia de una clase que implementa la interfaz, entonces todo funciona bien.

¿Sabe alguien cómo solucionar este problema?

Aquí está mi código de prueba:

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
    }
}

Código fuente del módulo:

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);
        }
    }

La salida de 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
fuente
1
Información adicional: Es posible crear inyector con una instancia simulada en cualquier módulo. He creado correctamente el inyector en el método "test01 ()". Pero si el Inyector es creado por RoboUnitTestCase, la aplicación falla.
— Andrey
16
El código fuente de RoboUnitTestCase.google.com/p/roboguice/source/browse/roboguice/src/main/… dice "Asegúrese de usar una de las anotaciones de prueba @ * Y comience el nombre de su caso de prueba con" prueba "" pero no está anotado @Beforey su prueba no está anotada @Test...
— Paul D'Ambra
2
Parece que no es directamente un problema de Java ( signal 11 (SIGSEGV), fault addr 0000000). ¿Podría probar con otra versión de firmware (emulador o dispositivo)?
— Pierre-Henri
¿Podría darnos la definición de la interfaz InterfaceToMock, para que podamos reproducir el comportamiento exacto de AndroidMock.createNiceMock?
— Remco
Si una de las A fuera buena para ti, ¿podrías aceptarla? Q todavía está abierto.
— Glen Best

Respuestas:

5

Desafortunadamente, si hay un problema con los pasos de configuración para RoboGuice y las pruebas unitarias, puede obtener este tipo de error. No hay una respuesta corta mágica, sino más bien un conjunto de pasos a seguir exactamente.

Por cierto, estás usando RoboGuice 1.1 - AbstractAndroidModule y RoboUnitTest ya no existen en RoboGuice 2.0. RoboGuice 1.1 está obsoleto, por lo que la mejor solución general es pasar a la versión más nueva de acuerdo con estas instrucciones Actualización a 2.0 .

Sin embargo, en caso de que esté conectado a RoboGuice 1.1, aquí hay algunos pasos a seguir:

  • No genere archivos de código / compilación inconsistentes después de refactorizar / cambiar nombres de paquetes, etc. Elimine el código generado, realice una limpieza y compilación, incluso vuelva a crear un nuevo proyecto y copie los archivos fuente en formato.
  • Tenga el código de su aplicación en un proyecto (dependiente de RoboGuice, independiente de Instrumentación / RoboUnitTestCase / AndroidMock). El proyecto de código de su aplicación tiene dentro de lib: guice-2.0-no_aop.jar y roboguice-1.1.2.jar.
  • Tenga su código de prueba de unidad en otro proyecto que lo haga referencia (independiente de RoboGuice, independiente de Instrumentación / RoboUnitTestCase / AndroidMock). Instrucciones aquí antes de comenzar . Su proyecto de código de prueba tiene dentro de lib: AndroidMockGenerator.jar.

  • En su proyecto de aplicación, las clases de su aplicación + módulo se ven así:

    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;
}   
}

    Y

    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);
}

    }

  • En su proyecto de prueba, su clase de caso de prueba se parece a esto:

    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!");
}

    }

  • Asegúrese de que para el proyecto de prueba, el archivo AndroidManifest.xml tenga la siguiente entrada:

   <instrumentation android:name="android.test.InstrumentationTestRunner"
     android:targetPackage="com.mypackage"
     android:label="Tests for com.mypackage"/>
  • Antes de ejecutar la prueba, asegúrese de que su emulador esté iniciado y funcione correctamente, ejecutando primero una aplicación "Hello World" diferente y simple. Cuando esto tenga éxito, ejecute su aplicación. Por último, ejecute su proyecto de prueba.

Debería funcionar después de esto. ¡Mucha suerte y házmelo saber!

— Glen Best
fuente
0

Desafortunadamente, esto es un error en el propio Android. Vea el informe de errores aquí . La máquina virtual se bloquea cuando intenta buscar anotaciones en un proxy , que es lo que usa AndroidMock cuando se burla de una interfaz .

La solución alternativa es crear una instancia de una clase que implemente la interfaz, como señaló en su pregunta. Puede intentar hacer una clase abstracta pura que implemente la interfaz sin implementar ningún método, luego use AndroidMock para simular esa clase en lugar de la interfaz. Esto debería evitar la creación de un Proxy.

— svattom
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.