从JUnit到Rspec的尝试

如今，各种测试框架层出不穷，每一种框架都有其独特性以及各自的优势。本人由于工作的原因，分别先后接触了JUnit以及Respec两套测试框架，虽然研究的不深，但也就这两套框架谈一谈自己的理解。重点主要针对于Rspec框架。

JUnit介绍    

 众所周知，JUnit是一个用Java编写而成的单元测试框架。利用JUnit，我们可以通过编写简单的测试代码，方便的进行白盒测试，也可以说：在了解了被测代码如何工作的前提下，对其内部结构的正确性进行自动化的测试。在JUnit的官网上，我们可以看到有关JUnit更为正统的释义——JUnit是一个开放源代码的简单框架，用来编写和运行可重复的测试（也被称为回归测试）。它是致力于单元测试框架的XUnit架构的一种实现。其中包含了：

1.用于检测预期结果的Assertions

2.用于共享测试数据的Test Fixtures

3.用于运行测试的Test Runners

    在使用JUnit时，其主要投放场景是：a.与开发人员约定好要测的内部方法、或是对外接口（方法名称、参数个数、参数类型等），两边同时开工，开发提测，运行JUnit测试代码。b.根据开发已写好的代码，编写测试代码，校验其正确性。这两种情景都很常见，具体采用哪种，视时间宽松程度而定。

    由于JUnit在很多平台工具上的集成（ANT,Maven,Eclipse,IntelliJ IDEA等），以及配有大量的插件（dbUnit,xmlUnit等），以及其易用性，使其仍是当今单元测试框架的首选。

Rspec介绍    

    前不久，由于需要对Kelude平台建立起一套测试体系，于是便研究起来Respec这一BDD测试框架。说起BDD，我想大家都不陌生，其英文全称为Behaviour Driven Development，即行为驱动开发。Respec就是Ruby社区中最为流行的行为驱动测试框架。关于BDD更详细的介绍，大家可以参考http://qa.taobao.com/?p=11630这篇文章，这里就不再过多介绍。

    要想真正用好Respec，就要遵循其背后的测试思想——测试先行。这也是与JUnit等单元测试框架最大的不同之处。所谓测试先行，就是要求我们，在开发人员编码工作之前，先写好测试用例，然后由测试来推动开发工作。通俗解释为：在设计实现一个功能之前，先考虑好如何来测试这个功能，测试的代码完成后，再编写功能实现代码，并且使得该测试用例运行通过，即完成了系统的一个功能模块。这与通常的JUnit使用场景背道而驰。

    如果在接触Respec的初期，就要求编写Respec测试用例，和编写功能代码的人员角色分开，我想这对于开发人员来说，应该是非常被动和痛苦的，同时也会很大程度上限制开发人员的创造性。因为功能代码的编写目的由原来的实现功能，变为了如今的通过测试用例，无论如何对于开发人员都是一种挑战。因此，初期尝试Respec阶段，我建议测试用例和功能代码的编写都由一个人来承担。也就是说，自己根据业务需求，先写好Respec测试用例，然后再编写功能代码，而编写功能代码的目的就是为了通过测试。这样做的好处，不仅可以最大程度的理解Resepc背后的思想，同时也会逼迫开发人员为了满足易测性，从而写出简洁、高质量的代码。这些优点，只有真正尝试过Respec后，才会深有感触。

   Respec在Rails框架中，不仅能针对MVC的Controller层、Model层、View层，进行分层测试，同时也可以针对例如路由等其它层面进行测试，可以说是功能非常全面。

Rspec初体验

    最后，针对于Rails应用搭建Respec环境、以及一些常用的插件做一下简短介绍：

 1.假设Ruby、Rails环境均已安装完成，安装Rspec插件

     gem install rspec

 2. 安装测试数据准备工具Factory Girl

      gem install factory_girl_rails

 3. 安装测试脚本对代码覆盖率的检测工具RCov

      gem install rcov

以上三步安装了进行Respec测试最常用的几个工具。

所有测试代码放在spec目录下，并且与功能代码的目录结构相对应。

下面附上一个Rspec代码文件：

 

如上图：

let 方法主要针对数据准备声明

Factory :XXX 从FactoryGirl 插件中取出预先准备好的数据

describe 对应于一个测试集

it 对应于一个测试用例

 

    每个测试集和测试用例都配有各自的描述信息（测试集名、用例名），这些都是写进测试代码中的，这样做，不仅增加了代码的可读性，同时在执行用例时，一旦用例报错，可以很方便的查看到是对应于哪一部分业务规则的代码出了问题。在测试用例中用通用语言把系统的行为描述出来，把测试代码作为系统的定义文档，将系统的设计和测试用例结合起来，这即是BDD所倡导的。

 

    当想查看测试用例脚本对于功能代码的覆盖情况时，我们可以使用RCov这个工具，通过它，不仅可以通过命令行的形式查看到覆盖率数据，也可以以HTML网页形式查看，非常清晰、具体。