Le processus se bloque lors de la création de l'injecteur RoboGuice, s'il existe une instance simulée dans un module

85

J'ai un problème avec l'utilisation des frameworks RoboGuice et AndroidMock dans les tests unitaires. J'ai créé un projet simple pour montrer mon problème. Ici, je crée une instance simulée et je l'enregistre dans RoboGuice. Mais le processus plante entre les méthodes "setUp ()" et "test01 ()". Comme je suppose, en fait, le processus se bloque lorsque l'injecteur est créé, si un module contient une instance simulée.

Si je remplace l'instance simulée par une instance d'une classe qui implémente l'interface, tout fonctionne bien.

Quelqu'un sait-il comment résoudre ce problème?

Voici mon code de test:

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

Code source du module:

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 sortie 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
source
1
Informations supplémentaires: Il est possible de créer un injecteur avec une instance simulée dans n'importe quel module. J'ai créé avec succès Injector dans la méthode "test01 ()". Mais si l'injecteur est créé par RoboUnitTestCase, l'application est plantée.
— Andrey
16
Le code source de RoboUnitTestCase.google.com/p/roboguice/source/browse/roboguice/src/main/… indique "Assurez-vous d'utiliser l'une des annotations @ * Test ET commencez le nom de votre scénario par" test "" mais votre configuration n'est pas annoté @Beforeet votre test n'est pas annoté @Test...
— Paul D'Ambra
2
Il semble que ce ne soit pas directement un problème java ( signal 11 (SIGSEGV), fault addr 0000000). Pourriez-vous essayer avec une autre version de firmware (émulateur ou appareil)?
— Pierre-Henri
Pourriez-vous nous donner la définition de l'interface InterfaceToMock, afin que nous puissions reproduire le comportement exact d'AndroidMock.createNiceMock.
— Remco
Si l'un des A était bon pour vous, pourriez-vous l'accepter? Q est toujours ouvert.
— Glen Best

Réponses:

5

Malheureusement, s'il y a un problème avec les étapes de configuration de RoboGuice et des tests unitaires, vous pouvez obtenir ce type d'erreur. Pas de réponse courte magique, mais plutôt un ensemble d'étapes à suivre exactement.

BTW, vous utilisez RoboGuice 1.1 - AbstractAndroidModule et RoboUnitTest n'existent plus dans RoboGuice 2.0. RoboGuice 1.1 est obsolète, donc la meilleure solution globale consiste à passer à la dernière version en suivant ces instructions Mise à niveau vers 2.0 .

Cependant, juste au cas où vous seriez attaché à RoboGuice 1.1, voici quelques étapes à suivre:

  • Ne pas avoir de code généré / fichiers de construction incohérents après la refactorisation / modification des noms de package, etc.
  • Ayez le code de votre application dans un seul projet (dépend de RoboGuice, Instrumentation / RoboUnitTestCase / AndroidMock indépendant). Votre projet de code d'application a dans lib: guice-2.0-no_aop.jar et roboguice-1.1.2.jar.
  • Demandez à votre code de test unitaire dans un autre projet qui le référence (RoboGuice indépendant, Instrumentation / RoboUnitTestCase / AndroidMock indépendant). Instructions ici avant de commencer . Votre projet de code de test a dans lib: AndroidMockGenerator.jar.

  • Dans votre projet d'application, vos classes App + Module ressemblent à ceci:

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

    Et

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

    }

  • Dans votre projet de test, votre classe de cas de test ressemble à ceci:

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

    }

  • Assurez-vous que pour le projet de test, le fichier AndroidManifest.xml contient l'entrée suivante:

   <instrumentation android:name="android.test.InstrumentationTestRunner"
     android:targetPackage="com.mypackage"
     android:label="Tests for com.mypackage"/>
  • Avant d'exécuter votre test, assurez-vous que votre émulateur est démarré et fonctionne correctement, en exécutant d'abord une application différente et simple «Hello World». Lorsque cela réussit, exécutez votre application. Enfin, exécutez votre projet de test.

Devrait fonctionner après cela. Bonne chance et faites le moi savoir!

— Glen Best
source
0

Malheureusement, il s'agit d'un bogue dans Android lui-même. Voir le rapport de bogue ici . La machine virtuelle se bloque lorsqu'elle tente de rechercher des annotations sur un proxy , ce qu'utilise AndroidMock pour se moquer d'une interface .

La solution de contournement consiste à créer une instance d'une classe qui implémente l'interface, comme vous l'avez souligné dans votre question. Vous pouvez essayer de créer une classe abstraite pure qui implémente l'interface sans implémenter de méthodes, puis utiliser AndroidMock pour simuler cette classe au lieu de l'interface. Cela devrait éviter la création d'un proxy.

— svattom
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.