欢迎光临
梦想从学习开始!

在单元测试,集成测试与功能测试中模拟依赖| 小熊测试

本文主要介绍 在单元测试,集成测试与功能测试中模拟依赖| 小熊测试,小熊希望对大家的学习或者工作具有一定的参考学习价值,在测试领域有所提升和发展。

  亲爱的读者,你好。

  最初,这只是一个对 Reddit 上 Robolectric and Dagger 2 的评论。但是由于内容很多所以我决定将它总结为一篇博客,祝您阅读愉快。

  依赖注入(DI)框架 & 单元测试

  单元测试中,我们经常隔离测试一个类或方法。如果被测试的是有行为的类,如RestApi,DataManager等,你需要模拟它的依赖;如果被依赖的是“值类”,如User,Message等,你可以直接使用它们(也可以模拟它们)。

  这意味着通常我们并不需要在单元测试中使用 DI 框架,因为单元测试目标只是一个类或一个方法,而不是几个类。目标类应该通过以下方式获取依赖:

  · 通过构造方法(推荐方式)

  · 通过方法或字段

  99% 的单元测试都不需要 DI 框架,通常只有像Activity,Fragment,View或Service这样在创建以后需要一系列依赖的类需要与 DI 框架交互。然而,我提倡使用 MVP 等模式将逻辑从 Android 框架类中移出,并且使用功能(UI)测试而不是单元测试来覆盖它们。

  DI 框架 & 集成测试

  一般而言,你也不必在集成测试中使用 DI 框架。因为集成测试只是简单的将几个类关联起来测试它们的集成。如果你的代码是依赖注入友好的(DI-friendly),你可以不使用 DI 框架将需要的依赖传入。

  如果你确实需要通过 DI 框架提供模拟依赖,并且你使用了 Robolectric,请继续往下看。

  DI 框架 & 功能(UI)测试

  此类测试确实需要使用 DI 框架模拟依赖。因为一般来说,功能测试针对的是整个应用,而不是几个类。

  如果你需要在instrumentation测试(Espresso,Robotium,或单纯的 instrumentation 测试等)中使用 DI 框架,请继续往下看。

  如何使用 Dagger 2 和 Robolectric 在测试中模拟并注入依赖?

  (通常适用于集成测试)

  主要思路:对于 Roboletric 测试,可以自定义一个Application类,在其中模拟依赖。

  你可以在 application 类中定义一个返回DaggerAppComponent的内部类Builder类对象,然后在集成测试时使用使用适当的子类覆盖该 application 类!

  application 类

public class MyApp extends Application {

@NonNull // Initialized in onCreate.

AppCompontent appComponent;

@Override

public void onCreate() {

appComponent = prepareAppComponent().build();

}

// Here is the trick, we allow extend application class and modify AppComponent.

@NonNull

protected DaggerAppComponent.Builder prepareAppComponent() {

return new DaggerAppComponent.Builder();

}

}

  用于集成测试的 application 类

public class MyIntegrationTestApp extends MyApp {

@Override

@NonNull

protected DaggerAppComponent.Builder prepareAppComponent() {

return super.prepareAppComponent()

.someModule(new SomeModule() {

@Override

public SomeDependency provideSomeDependency(@NonNull SomeArgs someArgs) {

return mock(SomeDependency.class); // You can provide any kind of mock you need.

}

})

}

}

  然后通过自定义RobolectricGradleTestRunner类使用该类。

  自定义带有定制化 application 类的 Robolectric 测试执行器

public class IntegrationRobolectricTestRunner extends RobolectricGradleTestRunner {

// This value should be changed as soon as Robolectric will support newer api.

private static final int SDK_EMULATE_LEVEL = 21;

public IntegrationRobolectricTestRunner(@NonNull Classclazz) throws Exception {

super(clazz);

}

@Override

public Config getConfig(@NonNull Method method) {

final Config defaultConfig = super.getConfig(method);

return new Config.Implementation(

new int[]{SDK_EMULATE_LEVEL},

defaultConfig.manifest(),

defaultConfig.qualifiers(),

defaultConfig.packageName(),

defaultConfig.resourceDir(),

defaultConfig.assetDir(),

defaultConfig.shadows(),

MyIntegrationTestApp.class, // Here is the trick, we change application class to one with mocks.

defaultConfig.libraries(),

defaultConfig.constants() == Void.class ? BuildConfig.class : defaultConfig.constants()

);

}

}

  如何在 Instrumentation 测试中使用 Dagger 2 模拟并注入依赖?

  Google 的那帮兄弟建议使用 flavors,但我并不推荐使用它。因为 flavors 越多,构建应用花费的时间越长,你也会越不喜欢 Gradle 以及整个构建过程。如果可以避免,尽量不要使用 flavors。

  主要思路:与 Roboletric 测试相似——通过修改Application类来实现,不过这次是针对 Instrumentation 测试。

  为了实现此方法,你需要自定义 Instrumentation 测试执行器,并将它们添加到build.gradle中。

public class CustomInstrumentationTestRunner extends AndroidJUnitRunner {

@Override

@NonNull

public Application newApplication(@NonNull ClassLoader cl,

@NonNull String className,

@NonNull Context context)

throws InstantiationException,

IllegalAccessException,

ClassNotFoundException {

return Instrumentation.newApplication(CustomApp.class, context);

}

}

  将该类添加到build.gradle中:

android {

defaultConfig {

testInstrumentationRunner 'a.b.c.CustomInstrumentationTestRunner'

}

}

  代码示例:我已经将内容更新到 #qualitymatters app中,并做了分析,展示了在单元测试,集成测试和功能测试中模拟依赖的方式。 因为我们在测试真正应用时需要分析,但在实验中却不想分析!也许你已经注意到了,我们没有添加 flavors。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小熊分享邦(www.xxfxb.com),希望大家能坚持软件测试之路,谢谢。

赞(0) 打赏
未经允许不得转载:小熊分享邦 » 在单元测试,集成测试与功能测试中模拟依赖| 小熊测试

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏