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

摘要：在世界级的安卓测试开发流第一部分，作者开始了安卓测试开发流的讨论。这个测试用例的测试对象是，部分指令集仅涉及执行的指令和。测试的粒度则应当和测试范围相当。一旦我们能够测试产品需求是否正确实现，我们必须继续测试开发流。

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

测试自动化对于软件开发的成功是至关重要的

可测试性代码对编写某些特定类型的测试是必须的

有些开发者在不确定测试内容和测试方法的情况下，就开始编写测试

测试的质量和可靠度通常达不到我们的期望

一个测试开发流对于定义测试内容和方法是必要的

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

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

测试服务器端的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 官方博客