给安卓开发小白们的unit test指南 - 这也能测？这也要测？

长久以来，测试对于很多安卓开发小白们都是一个盲区。这个很大程度上是因为做app，大家都习惯了自己手动测试feature，毕竟是所见即所得的东西，点几个按钮看看能不能按照要求展示几个页面好像并不是那么难。其次是因为很多代码写的并不是特别可测 （比如代码都写在activity里面），导致没法进行单元测试。

以上的几个原因，最终导致了很多接触安卓开发没多久的朋友(尤其是在小厂，对迭代速度要求更快的地方)没怎么接触过安卓的单元测试，也不知道test coverage是什么，更加意识不到单元测试的重要性。产生了一种类似于咱们大学刚接触高等数学证明题的感觉:

对应到咱们今天讲的测试，很多人在看完同事写的测试代码之后也有类似的震惊。“这还要测？” “这也能测？”

今天我想着重讲一下安卓开发中单元测试的意义，来说明“这也要测”的意义。同时提供一些安卓测试中的小技巧，把“这也能测”的问题一并给解决 😃

单元测试的意义

对于安卓开发来说，大部分小白们对于单元测试处于懵逼的状态。不知道测试有啥用。我刚刚开始工作的时候就特别不喜欢写test，觉得是浪费时间。我的想法是，就算单元测试成功了，你的app跑起来也不一定能work啊。。。 所以还不如专心在手动测试上。

其实这个想法也不能说完全错，甚至可以说是对了一半。因为单元测试成功不一定代码app的功能就没问题。但是反过来说，如果单元测试都不对，那app的功能肯定有问题。

软件开发中有一个大假设，就是如果你的每个模块都能自己独立且正确运行的话，这个软件就大概率能正确的运行。比如，如果我们app中每个class都能通过各种的独立单元测试，那么把他们拼接起来这个app应该就没毛病了。

单元测试位于软件开发测试的金字塔的最底层，也是最重要的那一层。单元测试都跑不过，就别谈集成测试 ， UI 测试了。安卓也不例外。

可能光这么说大家还是体会不到单元测试的好处。那么我就选一个方面来具体的说说单元测试在实际开发过程中，可以给我们带来什么好处。

怎么改？单元测试说了算

在大厂工作的朋友肯定都有过接手别人项目的经验，当你在尝试修改某一个class的时候，你怎么确定你添加的代码就是对的呢 (在不运行app做手动测试之前)？

答案就是单元测试。unit test在很多情况下，可以当做你修改代码的规则. class A 哪里改了会影响到class B，都可以在跑unit test之后发现，这也是你作为一个项目后来者了解细节的方式。

用一个我以前自己类似的经历做例子。假如有以下MVP pattern的代码：

class Presenter{
    enum Status{
       LARGE,
       MEDIUM
    }
    
    public Status getFinancialStatus(int size){
        if(size < 1000){
           return Status.SMALL
        }