世界级的安卓测试开发流！（安卓工程测试）

世界级的安卓测试开发流！（安卓工程测试）

测试自动化对于软件开发的成功是至关重要的可测试性代码对编写某些特定类型的测试是必须的有些开发者在不确定测试内容和测试方法的情况下，就开始编写测试测试的质量和可靠度通常达不到我们的期望一个测试开发流对于定义测试内容和方法是必要的

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

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

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

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

以下测试是关于 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指令。

范围:

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

基础设施:

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

结果:

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

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