在开发完移动应用并和手动QA团队合作了数年后,我们决定开始写测试。作为工程师,我们知道, 自动化测试是成功的移动开发之关键。 在这篇博客里,将会分享我们的故事,Karumi测试故事, 开始于几年前。这是系列博客的第一篇,我们将会囊括世界级的 Android测试流程的所有方面。
几年前,我们开始为移动应用写测试。我们对测试了解有限,所以我们致力于接受测试并使用最常用的框架来做单元测试,一个简单的test runner和mocking库。过了一段时间我们遇到了问题:
是不是很可怕? 我们花了很多时间去克服这些挑战,在某个时刻我们意识到是方法错了。即便测试覆盖率很高,我们的软件仍然在出错。最坏的是,从我们的测试中,无法得到任何反馈。 解决我们的问题的关键是识别出我们一直碰到的问题所在:
这是我们决定停下,并开始思考为什么我们对自己的测试感觉不爽。我们快速需要找到问题的解决方案。我们的项目告诉说我们做错了,我们需要解决方案, 我们需要一个测试开发流程 。话虽如此,一个测试开发流程并不总是提高你项目质量的最先要去完善的东西。
一个测试开发流程定义了测什么、怎么测。用什么工具,为什么用?测试的范围是什么? 即便有良好的测试开发流程,可测试的代码对有自信去写测试仍然是必须的 ,因为大部分的测试是不可能的,或者至少,很难去写。如果你的代码没有准备好,与代码以及单元或集成范围最贴近的测试并不是那么容易去写的。因此,我们决定带着这些目标,首先识别出应用中的问题,然后去解决它们。那么问题来了,如果我们的代码能够是完美的,我们对它有何期望呢?期望是:
在重构之前代码一团糟。软件职责丢失在代码的行与行之间。实现细节是完全暴露的,activities和fragments负责处理软件的状态,到处都是软件状态。另外,我们的业务逻辑和框架是耦合的。带着这些问题,我们决定把应用架构改成其他更有结构的东西。 我们使用的架构是 “Clean架构” 。除了架构的核心内容,我们还应用了一些和GUI应用相关模式像是MVP和MMVM,以及数据处理相关的模式像是Repository模式 。架构详情和这篇博客没有关系(我们会在未来的博文中讨论到它),“Clean Architecture”的 核心元素 与 最重要的SOLID原则之一, 依赖倒置原则 相关。
依赖倒置原则提出你的代码必须依赖于抽象而不是具体实现。这个原则,仅仅是这个原则就是通向成功的钥匙。它是 改变我们的代码并适配测试策略以有效克服我们手上问题的关键 。依赖于抽象既无关于依赖注入框架,也无关于使用Java接口来定义类的API。然而,它与隐藏细节有关。根据不同角色,软件职责改变的点,引入 测试替身(TestDouble) 的点去创建层,大大限制了测试的范围。
通过依赖倒置原则,我们能够去选择正确数量的代码去测试。一旦这些点清晰了,我们就停下为所有的mocks去写测试。我们能够使用准确数字的mocks去覆盖一个测试用例,并确保我们在测试软件状态而不仅仅是组件之间的交互。
一旦应用架构清晰了,我们开始 定义我们的测试开发流程。我们的目标是回答2个问题:我们想要测试什么?我们如何去测试它? 在尝试找出如何分割测试,并用简单又可读的方式去写以后,我们注意到层次分离是最完美的出发点。结果,解决方案变得清晰:
我们想要测试什么?
我们想要怎么去测试?
参考: