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

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 l’enregistre dans le RoboGuice. Mais le processus se bloque entre les méthodes “setUp ()” et “test01 ()”. Comme je suppose, en réalité, le processus se bloque lorsque l’injecteur est créé, si un module a une instance simulée à l’intérieur.

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

Est-ce que quelqu’un sait comment résoudre ce problème?

Voici mon code de test:

public class testInjectMock extends RoboUnitTestCase { 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 ssortingng 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 

Malheureusement, s’il ya 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, mais plutôt une série d’étapes à suivre exactement.

BTW, vous utilisez RoboGuice 1.1 – AbstractAndroidModule & RoboUnitTest n’existent plus dans RoboGuice 2.0. RoboGuice 1.1 est obsolète, la meilleure solution consiste donc à passer à la version la plus récente conformément à ces instructions. Mise à niveau vers la version 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é de manière incohérente / construire des fichiers après avoir refactoring / modification des noms de paquet, etc. Supprimer le code généré, faire un Clean & Build, même recréer un nouveau projet et copier les fichiers source dans.
  • Ayez votre code d’application dans un projet (RoboGuice dépendant, indépendant Instrumentation / RoboUnitTestCase / AndroidMock). Votre projet de code d’application a dans lib: guice-2.0-no_aop.jar et roboguice-1.1.2.jar.
  • Ayez votre code de test unitaire dans un autre projet qui le référence (indépendant de RoboGuice, indépendant de Instrumentation / RoboUnitTestCase / AndroidMock). 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 scénario 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 { @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 comporte l’entrée suivante:

   
  • Avant d’exécuter votre test, assurez-vous que votre émulateur est démarré et qu’il fonctionne normalement en exécutant d’abord une application simple “Hello World”. Lorsque cela réussit, exécutez votre application. Enfin, exécutez votre projet de test.

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

Malheureusement, c’est un bug dans Android lui-même. Voir le rapport de bogue ici . La machine virtuelle se bloque lorsqu’elle essaie de rechercher des annotations sur un proxy , ce que AndroidMock utilise pour simuler une interface .

La solution consiste à créer, par exemple, 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 utilisez AndroidMock pour simuler cette classe au lieu de l’interface. Cela devrait éviter la création d’un proxy.