Збій процесу під час створення інжектора RoboGuice, якщо в будь-якому модулі є знущаний екземпляр


85

У мене проблема з використанням фреймворків RoboGuice та AndroidMock при модульному тестуванні. Я створив простий проект, щоб показати свою проблему. Тут я створюю знущаний екземпляр і реєструю його в RoboGuice. Але процес аварійно завершує роботу між методами "setUp ()" і "test01 ()". Як я здогадуюсь, насправді процес аварійно завершується, коли створюється Інжектор, якщо в будь-якому модулі є знущаний екземпляр.

Якщо я замінюю знущаний екземпляр екземпляром класу, який реалізує інтерфейс, тоді все працює нормально.

Хтось знає, як вирішити цю проблему?

Ось мій тестовий код:

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

Вихідний код модуля:

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

Вихід 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

1
Додаткова інформація: У будь-якому модулі можна створити інжектор з глузливим екземпляром. Я успішно створив Інжектор методом "test01 ()". Але якщо інжектор створений RoboUnitTestCase, програма розбивається.
Андрій

16
Джерело RoboUnitTestCase code.google.com/p/roboguice/source/browse/roboguice/src/main / ... каже : «Переконайтеся , що ви використовуєте один з @ * Тестових анотацій і почати ім'я вашого TestCase з" тестом " , " але ваша налаштуванням не коментується, @Beforeа ваш тест не коментується @Test...
Пол Д'Амбра

2
Здається, це не безпосередньо проблема Java ( signal 11 (SIGSEGV), fault addr 0000000). Не могли б ви спробувати іншу версію мікропрограми (емулятор чи пристрій)?
П'єр-Анрі

Не могли б ви дати нам визначення інтерфейсу InterfaceToMock, щоб ми могли відтворити точну поведінку AndroidMock.createNiceMock.
Ремко

Якби одне з «А» було вам добре, чи могли б ви прийняти його? Q все ще відкрито.
Glen Best

Відповіді:


5

На жаль, якщо є проблема з кроками налаштування для RoboGuice та модульного тестування, ви можете отримати подібну помилку. Ніякої чарівної короткої відповіді, а скоріше набір кроків, яких слід точно виконувати.

До речі, ви використовуєте RoboGuice 1.1 - AbstractAndroidModule & RoboUnitTest більше не існують у RoboGuice 2.0. RoboGuice 1.1 застарілий, тому найкращим загальним рішенням є перехід на найновішу версію відповідно до цих інструкцій Оновлення до 2.0 .

Однак, на випадок, якщо ви прив’язані до RoboGuice 1.1, виконайте наведені нижче дії:

  • Не майте невідповідних згенерованих файлів коду / збірки після рефакторингу / зміни назв пакетів тощо. Видаліть згенерований код, виконайте Clean & Build, навіть відтворіть новий проект та скопіюйте вихідні файли в.
  • Розмістіть код програми в одному проекті (залежно від RoboGuice, незалежний від Instrumentation / RoboUnitTestCase / AndroidMock). У вашому проекті коду програми є lib: guice-2.0-no_aop.jar та roboguice-1.1.2.jar.
  • Нехай ваш модульний тестовий код буде в іншому проекті, який посилається на нього (незалежний від RoboGuice, незалежний від Instrumentation / RoboUnitTestCase / AndroidMock). Інструкції тут перед початком роботи . У вашому проекті тестового коду є lib: AndroidMockGenerator.jar.
  • У вашому проекті програми ваші класи App + Module виглядають приблизно так:

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

    І

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

    }

  • У вашому тестовому проекті клас вашого тестового кейсу виглядає приблизно так:

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

    }

  • Переконайтеся, що для тестового проекту файл AndroidManifest.xml містить такий запис:

   <instrumentation android:name="android.test.InstrumentationTestRunner"
     android:targetPackage="com.mypackage"
     android:label="Tests for com.mypackage"/>
  • Перш ніж запускати тест, переконайтеся, що ваш емулятор запущений і працює здорово, спершу запустивши інший, простий додаток "Hello World". Коли це вдасться, запустіть програму. Нарешті, запустіть свій тестовий проект.

Має працювати після цього. Удачі та дайте мені знати!


0

На жаль, це помилка самого Android. Дивіться звіт про помилку тут . Віртуальна машина аварійно завершує роботу, коли намагається шукати анотації на проксі-сервері , що і використовує AndroidMock при знущанні над інтерфейсом .

Обхідним шляхом є створення в екземплярі класу, який реалізує інтерфейс, як ви зазначили у своєму питанні. Ви можете спробувати створити чисто абстрактний клас, який реалізує інтерфейс, не застосовуючи жодних методів, а потім використовувати AndroidMock, щоб знущатись над цим класом замість інтерфейсу. Це має уникнути створення проксі-сервера.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.