单元测试

JUnit Rule是什么 一个JUnit Rule就是一个实现了TestRule的类，这些类的作用类似于@Before、@After，是用来在每个测试方法的执行前后执行一些代码的一个方法。 如果你不清楚@Before、@After这些Annotation的意思，Chances are你还不了解Junit的使用，建议先看这篇文章。 那为什么不直接用这些annotation呢？这是因为它们都只能作用于一个类，如果同一个setup需要在两个类里面同时使用，那么你就要在两个测试类里面定义相同的@Before方法，然后里面写相同的代码，这就造成了代码重复。有的人说你可以用继承啊，首先我想说，我很讨厌继承这个东西，所以如果可以不用继承的话，我就不会用；再次我想说，如果你不讨厌继承的话，从现在开始，你也应该慢慢的讨厌它了。 此外，JUnit Rule还能做一些@Before这些Annotation做不到的事情，那就是他们可以动态的获取将要运行的测试类、测试方法的信息。这个在接下来的一个例子里面可以看到。 怎么用JUnit Rule？ 使用框架自带的Rule 很多测试框架比如JUnit、Mockito自带给我们很多已经实现过好了的JUnit Rule，我们可以直接拿来用。比如Timeout，TemporaryFolder，等等。这些Rule的使用方法非常简单。定义一个这些类的public field，然后用@Rule修饰一下就好了。比如 public class ExampleTest { @Rule public Timeout timeout = new Timeout(1000); //使用Timeout这个 Rule， @Test public…

大家好，我是蘑菇街支付金融部门的邹勇，花名叫小创。今天很高兴跟大家分享一下安卓的单元测试在蘑菇街支付金融的实践。下面，我们从为什么开始。 为什么要写单元测试 首先要介绍为什么蘑菇街支付金融这边会采用单元测试的实践。说起来比较巧，刚开始的时候，只是我一个人会写单元测试。后来老板们知道了，觉得这是件很有价值的事情，于是就叫我负责我们组的单元测试这件事情。就这样慢慢的，单元测试这件事情就成了我们这边的正常实践了。再后来，在公司层面也开始有一定的推广。 要说为什么要写单元测试的话，我相信大部分人都能承认、也能理解单元测试在保证代码质量，防止bug或尽早发现bug这方面的作用，这可能是大家觉得单元测试最大的作用。然而我觉得，除了这方面的作用，单元测试还能在很大程度上改善代码的设计，同时还能节约时间，让人工作起来更自信、更开心，以及其他的一些好处。这些都是我的切身感受，我相信也是多数真正实践过单元测试的人的切身感受，而不是为了宣传这个东西而说的好听的大话。 说到节约时间，大家可能就会好奇了，写单元测试需要时间，维护单元测试代码也需要时间，应该更费时间才对啊？ 这就是在开始分享之前，我想重点澄清的一点，那就是，单元测试本身其实不会占用多少时间，相反，还会节约时间。只是：1. 学习如何做单元测试需要时间；2. 在一个没有单元测试的项目中加入单元测试，需要一定的结构调整的时间，因为一个有单元测试跟没有单元测试的项目，结构上还是有较大不同的。 打个比方，开车这件事情，需要很多时间吗？我相信很少人会说开车这件事情需要很多时间，而是：1. 学习开车，需要一定的时间；2. 如果路面不平的话，那么修路需要一定的时间。单元测试也是类似的情况。 那为什么说单元测试可以节约时间呢？简单说几点：1. 如果没有单元测试的话，就只能把app运行起来测试，这比运行一次单元测试要慢多了。2. 尽早发现bug，减少了debug和fixbug的时间。3. 重构的时候，大大减少手动验证重构正确性的时间。 所以，我希望大家能去掉"没时间写单元测试"这个印象，如果工作上安排太紧，没有时间学习如何做单元测试的话，可以自己私底下学，然后在慢慢应用到项目中。 单元测试简单介绍，以及void方法怎么测 接下来介绍我们这边是怎么做安卓单元测试的。首先澄清一下概念，在安卓上面写测试，有很多技术方案。有JUnit、Instrumentation test、Espresso、UiAutomator等等，还有第三方的Appium、Robotium、Calabash等等。我们现在讲的是使用JUnit和其他的一些框架，写可以在我们开发环境的JVM上面直接运行的单元测试，其他的几种其实都不属于单元测试，而是集成测试或者叫Functional test等等。这两者明显的不同是，前者可以直接在开发用的电脑，或者是CI上面的JVM上运行，而且可以只运行那么一小部分代码，速度非常快。而后者必须要有模拟器或真机，把整个project打包成一个app，然后上传到模拟器或真机上，再运行相关的代码，速度相对来说慢很多。 单元测试的定义相信大家都知道，就是为我们写的某一个代码单元（比如一个方法）写的测试代码。一个单元测试大概可以分为三个部分： setup：即new 出待测试的类，设置一些前提条件 执行动作：即调用被测类的被测方法，并获取返回结果 验证结果：验证获取的结果跟预期的结果是一样的 然而一个类的方法分两种，一种是有返回值的方法。一种是没有返回值的方法，即void方法。对于有返回值的方法，固然测试起来是很容易的，但是对于没有返回值的方法，该怎么测试呢？这里的关键是，怎么样获取这个方法的“返回结果”? 这里举一个例子来说明一下，顺便澄清一个十分常见的误解。比如说有一个Activity，管他叫DataActivity，它有一个public void loadData()方法, 会去调用底层的DataModel类，异步的执行一些网络请求。当网络请求返回以后，更新用户界面。…

我们写单元测试，一般都会用到一个或多个单元测试框架，在这里，我们介绍一下 JUnit4 这个测试框架。这是 Java 界用的最广泛，也是最基础的一个框架，其他的很多框架，包括我们后面会看到的 Robolectric，都是基于或兼容 JUnit4 的。 然而首先要解决的问题是。。。 为什么要使用单元测试框架 或者换句话说，单元测试框架能够为我们做什么呢？ 从最基本的开始说起，假如我们有这样一个类： public class Calculator { public int add(int one, int another) { // 为了简单起见，暂不考虑溢出等情况。 return one + another; }…