世界级的安卓测试开发流！

在「世界级的安卓测试开发流 — 第一部分」，做者开始了安卓测试开发流的讨论。咱们探讨了一个软件工程师开始编写测试，到发现测试开发中的相关问题的不断变化。 最后，获得了如下结论：

• 测试自动化对于软件开发的成功是相当重要的
• 可测试性代码对编写某些特定类型的测试是必须的
• 有些开发者在不肯定测试内容和测试方法的状况下，就开始编写测试
• 测试的质量和可靠度一般达不到咱们的指望
• 一个测试开发流对于定义测试内容和方法是必要的

所以，任何应用程序中测试的关键部分是：

• 业务逻辑的测试要独立于框架或库
• 测试服务器端的API集成
• 从用户的角度，使用黑盒测试验收标准

在本文中，咱们将探讨涉及这几个部分的几种测试方案，以确保一个稳固的测试开发流。

业务逻辑的测试要独立于框架或库：

首先，检查业务逻辑是否是真的实现预约的产品需求，是必不可少的。咱们须要将想要测试的代码隔离出来，而后模拟出不一样的初始场景，以配置某些组件在运行时的行为。而后，咱们选择想要执行的代码部分进行测试。以后，咱们须要在执行完测试对象后检查软件的状态是否正确。

这个测试方案的关键在于依赖反转原则。经过编写只依赖于抽象的代码，咱们就能够把软件分离成不一样的层级。为了得到依赖的实例，咱们只须要向某个对象发出请求。 或者，一旦实例生成，咱们也能得到之。 咱们的软件有不少部分须要建立代码来得到合做者的实例。这时，咱们会使用测试替身来模拟初始场景，或编写不一样的行为程序来设计咱们的测试。经过使用测试替身，咱们能同时模拟产品代码的行为和状态。 同时，它帮助咱们选择测试的范围，也即须要测试的代码量。没有依赖反转，全部的类须要独自获取本身的依赖。结果会致使类实现和依赖实现相耦合，这样就没有办法借用测试替身来切割产品代码的执行流程。

一般，在构造时传递类依赖是使用依赖反转的最有效机制。这个机制对采用测试替身已经足够。在构造时传递类依赖将帮助咱们建立相应的测试替身来替换依赖的实例。要谨记，使用服务定位器或依赖反转框架将有助于减小在应用依赖反转时所须要的样板， 虽然这并非强制的。

咱们将用一个具体例子（该测试和笔者几个月前开始开发的 Android GameBoy 模拟器有关）来演示如何测试咱们的业务需求。

如下测试是关于 GameBoy 内存管理单元（MMU）和 GameBoy BIOS 执行单元的。 咱们将检查产品需求（硬件模拟）是否正确实现。

public class MMUTest {  
  private static final int MMU_SIZE = 65536;
  private static final int ANY_ADDRESS = 11;
  private static final byte ANY_BYTE_VALUE = 0x11;

  @Test public void shouldInitializeMMUFullOfZeros() {
    MMU mmu = givenAMMU();

    assertMMUIsFullOfZeros(mmu);
  }

  @Test public void shouldFillMMUWithZerosOnReset() {
    MMU mmu = givenAMMU();

    mmu.writeByte(ANY_ADDRESS, ANY_BYTE_VALUE);
    mmu.reset();

    assertMMUIsFullOfZeros(mmu);   
  }

  @Test public void shouldWriteBigBytesValuesAndRecoverThemAsOneWord() {
    MMU mmu = givenAMMU();

    mmu.writeByte(ANY_ADDRESS, (byte) 0xFA);
    mmu.writeByte(ANY_ADDRESS +1, (byte) 0xFB);

    assertEquals(0xFBFA, mmu.readWord(ANY_ADDRESS));
  }
}

前三个测试是检查 GameBoy 的 MMU 实现是否正确。 成功的关键是总在测试执行完成后，检查 MMU 的状态是否正确。 全部测试都会检查 MMU 是否正确初始化。若是重置后MMU 是整洁的，写入2个字节后读出的是一个字符，那么最终读取就是正确的。为了测试模拟器软件的这个部分，咱们将测试范围缩小为一个类。

public class GameBoyBIOSExecutionTest {

  @Test 
  public void shouldIndicateTheBIOSHasBeenLoadedUnlockingTheRomMapping() {
    GameBoy gameBoy = givenAGameBoy();

    tickUntilBIOSLoaded(gameBoy);

    assertEquals(1, mmu.readByte(UNLOCK_ROM_ADDRESS) & 0xFF);
  }

  @Test
  public void shouldPutTheNintendoLogoIntoMemoryDuringTheBIOSThirdStage() {
    GameBoy gameBoy = givenAGameBoy();

    tickUntilThirdStageFinished(gameBoy);

    assertNintendoLogoIsInVRAM();
  }

  private GameBoy givenAGameBoy() {
    z80 = new GBZ80();
    mmu = new MMU();
    gpu = new GPU(mmu);
    GameLoader gameLoader = new GameLoader(new FakeGameReader());
    GameBoy gameBoy = new Gameboy(z80, mmu, gpu, gameLoader);
    return gameboy;
  }
  
}

在这两个测试中，咱们检查 BIOS 是否在不一样阶段都正确执行。BIOS执行结束后，在具体内存位置的一个字节必须被初始化为一个具体的值。而后，在第三阶段的最后，任天堂的logo必须已经加载到 VRAM。因为全套的BIOS执行是任何模拟器开发的关键部分，咱们决定采用更大的测试范围。这个测试用例的测试对象是 CPU，部分 CPU 指令集(仅涉及 BIOS执行的指令)和 MMU。 要检查执行的状态是否正确，咱们必须对 MMU的状态使用断言（assert）。要想显著的提高测试质量，一个关键就是检查软件执行后的最终状态，同时避免验证和其余组件之间的交互。由于即便和其余组件之间的交互都是正确的，最终状态依然多是错的。还要明确，这些测试的某些部分一样能够独立进行，如 CPU指令。

这些测试的另外一个主要亮点是使用测试替身来模拟和 Android SDK 相关的部分代码。在执行 BIOS 前，GameBoy 游戏必须加载进 GameBoy 的 MMU。然而，在测试期间，没有 Android SDK 可用，于是就不得不将其替换，转而从测试环境中加载 GameBoy的 rom。*咱们使用依赖反转原则不只用于隐藏实现细节，或者定义边界，*还用测试替身 FakeGameReader 来替代 AndroidGameReader 的产品代码，这意味着彻底不依赖框架和库进行代码测试。经过这样作，咱们建立了隔离的测试环境，同时调整了测试范围。

范围:

调整测试的范围是很是重要的。 开始编写测试前，咱们应当牢记测试范围能够帮助识别代码错误(取决于测试的规模)。缩小测试规模能带给咱们更丰富的错误反馈，而放大规模的测试则不能提供错误位置的精确信息。测试的粒度则应当和测试范围至关。

基础设施:

编写这些测试的基础设施至关明了。 咱们必须在依赖反转原则下编写可测试代码，并结合使用一个测试框架和一个模拟库。 模拟库用来生成模拟场景中须要的测试替身，或者用于替代部分产品代码的测试替身。请注意，这些框架和库不是强制使用的，可是很是推荐。

结果:

这个方案的结果颇有趣。 当遵循依赖反转原则时，咱们能独立于框架和库测试咱们产品代码中的业务逻辑。经过可重复的，易于编写和设计的测试，咱们能够建立隔离的测试环境。此外，咱们可以方便选择要测试的产品代码数量，并使用测试替身代替这部分代码，来模拟行为和不一样的场景。

一旦咱们可以测试产品需求是否正确实现，咱们必须继续测试开发流。接下来要测试的，就是在前一阶段使用测试替身替换的外部组件集成后是否执行正确。咱们将在下一篇博文中讨论，敬请期待！

原文地址：http://blog.karumi.com/world-class-testing-development-pipeline-for-android-part-2/

OneAPM Mobile Insight ，监控网络请求及网络错误，提高用户留存。访问 OneAPM 官方网站感觉更多应用性能优化体验，想阅读更多技术文章，请访问 OneAPM 官方技术博客。 本文转自 OneAPM 官方博客