How to Share Data between testcase

导读:
   Problem Summary
  How to easily share simple and complex test data instances between multiple TestCases? 如何便捷的在TESTCASE之间共享简单和复杂的数据实例
   Solution Summary
  Create a factory class that can generate required test data instances. 创建一个工厂类来产生所需的数据实例
   Explanation
  This recipe extends the Create a FlexUnit TestCaserecipe. 次此解决方案扩展了TestCaserecipe
  A common unit testing need is to have multiple different TestCases share the same or similar test data. This data maybe simple like an object which represents an Address or it maybe a complex object such as an Order which has many interrelated entities that must be setup in a particular manner. Instead of cutting and pasting code or trying to load data from an external resource to create and initialize such objects in each TestCase, the creation can be centralized into a factory. This type of test data centralization is referred to as the ObjectMother pattern. 一个寻常的单元测试,需要有多个测试用例共享相同或者相似的测试数据。这个数据也许仅仅是代表一个地址的对象,也许是一个复杂的对象,例如订单类什么的,必须通过特殊的方式构建,为了不在各个测试用例创建的时候剪切粘贴代码,初始化代码可以写成一个工厂类,这种在测试的时候数据创建工厂为核心的模式有的时候也称为对象母亲模式(OBJECT MOTHER)
  In its simplest form the ObjectMother is a single utility class with a static method for creating each type of object that is needed. 对象母亲的最简单形式是一个工具类,以及一系列创建各个数据的静态方法Typically the creation methods will come in two forms. The first form requires passing in values for each property that needs to be set and the method just assembles the object. The second form requires few or no arguments and the method provides realistic intelligent defaults for each field. As additional object types are needed they can use the lower level creation methods to build more and more complex objects. 特别的数据创建方法有两种形式,第一种形式需要传递那些需要设置值的对象。方法仅仅组装对象。第二种形式不需要参数,方法为各个域提供了缺省的值,因为要用到特定的对象类型,需要使用低级别的创建方法来创建更加复杂的对象
  Another benefit of the ObjectMother class is to provide testing constants or other magic values that many tests will reference. OM模式的另一个优点是提供测试常量或者其他魔数,如果测试中需要的话
  Below is an example of what a simple ObjectMother 下面是OM的一个简单例子implementation could look like:
  package
  {
  public class ObjectMother
  {
  public static const SHIPPING_ZIP_CODE:String = "0123";
  public static function createAddress(line:String, city:String, state:String, zip:String):Address
  {
  var address:Address = new Address();
  address.line = line;
  address.city = city;
  address.state = state;
  address.zip = zip;
  return address;
  }
  public static function createAddressShipping():Address
  {
  return createAddress("123 A Street", "Boston", "MA", SHIPPING_ZIP_CODE);
  }
  public static function createAddressBilling():Address
  {
  return createAddress("321 B Street", "Cambridge", "MA", "02138");
  }
  public static function createOrder(lineItems:Array = null):Order
  {
  var order:Order = new Order();
  order.shippingAddress = createAddressShipping();
  order.billingAddress = createAddressBilling();
  for each (var lineItem:LineItem in lineItems)
  {
  addLineItemToOrder(order, lineItem);
  }
  return order;
  }
  public static function addLineItemToOrder(order:Order, lineItem:LineItem):void
  {
  order.addLineItem(lineItem);
  }
  }
  }
  Starting with a simple Address object, a standardized parameter creation method createAddress() is defined. Two helper functions createAddressShipping() and createAddressBilling() are added to provide a quick way for TestCase methods to get access to fully fleshed out Address instances. The helper functions build on the generic createAddress() function utilizing any creation logic already written in that method. This tiered creation policy becomes handy as the types of objects being created become more complex, as shown in the createOrder() example, or there are many different steps to creating a single object. 从地址(ADRESS)对象开始,定义了一个标准化了各个参数的createAddress()方法,另外的createAddressShipping()createAddressBilling()方法使得创建一个完整的地址实例更加便捷
  Since new instances of objects are created each time a method is called, changes made by one TestCase won't have unintended side effects on other TestCases. At the same time since the test data objects are centralized changing the data in the ObjectMother to support a new test, may break existing brittle tests. This is usually a minor concern compared to the benefit of having readily accessible test data. 因为每次用到的数据都是新产生的,因此一个测试用例对数据的修改不会影响到另外的测试用例,但是与此同时由于数据产生的高度集中使得数据的修改可能造成现存的脆弱测试用例的中断,但是和OM带来的好处相比,这些是微不足道的。

本文转自
http://www.adobe.com/cfusion/communityengine/index.cfm?event=showdetails&productId=2&postId=6862

你可能感兴趣的:(单元测试,Access,Adobe)