http://www.molss.gov.cn/gb/news/2007-06/30/content_184630.htm

B)中华人民共和国劳动合同法实施条例(解释劳动法实施)

http://www.gov.cn/flfg/2008-09/19/content_1099500.htm

C)关于确立劳动关系有关事项的通知

http://www.law-lib.com/law/law_view.asp?id=92395

D)上海市女职工劳动保护办法

http://www.shanghai.gov.cn/shanghai/node2314/node3124/node3125/node3133/userobject6ai655.html

·                     C)的相关内容：

     用人单位未与劳动者签订劳动合同，认定双方存在劳动关系时可参照下列凭证：

(一)工资支付凭证或记录(职工工资发放花名册)、缴纳各项社会保险费的记录；

(二)用人单位向劳动者发放的“工作证”、“服务证”等能够证明身份的证件；

·                     B) 的相关内容：

第六条        用人单位自用工之日起超过一个月不满一年未与劳动者订立书面劳动合同的，应当依照劳动合同法第八十二条的规定向劳动者每月支付两倍的工资，并与劳动者补订书面劳动合同；劳动者不与用人单位订立书面劳动合同的，用人单位应当书面通知劳动者终止劳动关系，并依照劳动合同法第四十七条的规定支付经济补偿。(1，相当于给2倍工资，2，补合同，3，如果辞退，再按照有合同补偿）

第二十七条　劳动合同法第四十七条规定的经济补偿的月工资按照劳动者应得工资计算，包括计时工资或者计件工资以及奖金。

·                     A)的相关内容：

     第四十二条　劳动者有下列情形之一的，用人单位不得依照本法第四十条、第四十一条的规定解除劳动合同：

        （四）女职工在孕期、产期、哺乳期的

 　第四十七条　经济补偿按劳动者在本单位工作的年限，每满一年支付一个月工资的标准向劳动者支付。六个月以上不满一年的，按一年计算；不满六个月的，向劳动者支付半个月工资的经济补偿。

     第八十二条　用人单位自用工之日起超过一个月不满一年未与劳动者订立书面劳动合同的，应当向劳动者每月支付二倍的工资。

    用人单位违反本法规定不与劳动者订立无固定期限劳动合同的，自应当订立无固定期限劳动合同之日起向劳动者每月支付二倍的工资。

     第八十七条　用人单位违反本法规定解除或者终止劳动合同的，应当依照本法第四十七条规定的经济补偿标准的二倍向劳动者支付赔偿金。

 第十四条　无固定期限劳动合同，是指用人单位与劳动者约定无确定终止时间的劳动合同。

    用人单位与劳动者协商一致，可以订立无固定期限劳动合同。有下列情形之一，劳动者提出或者同意续订、订立劳动合同的，除劳动者提出订立固定期限劳动合同外，应当订立无固定期限劳动合同：

    （一）劳动者在该用人单位连续工作满十年的；

    （二）用人单位初次实行劳动合同制度或者国有企业改制重新订立劳动合同时，劳动者在该用人单位连续工作满十年且距法定退休年龄不足十年的；

    （三）连续订立二次固定期限劳动合同，且劳动者没有本法第三十九条和第四十条第一项、第二项规定的情形，续订劳动合同的。

    用人单位自用工之日起满一年不与劳动者订立书面劳动合同的，视为用人单位与劳动者已订立无固定期限劳动合同。

·                     D) 的相关内容：

第十一条对妊娠期的女职工，不应延长其劳动时间；

第十四条女职工产假分别按下列情况执行：

     （一）单胎顺产者，给予产假九十天，其中产前休息十五天，产后休息七十五天。

第十五条女职工生育后，在其婴儿一周岁内应照顾其在每班劳动时间内授乳两次（包括人工喂养）。每次单胎纯授乳时间为三十分钟，亦可将两次授乳时间合并使用。多胞胎生育者，每多生一胎，每次哺乳时间增加三十分钟。

 第十八条女职工在产假期间的工资照发。按本规定享受的产前假和哺乳假的工资按本人原工资的百分之八十发给。单位增加工资时，女职工按规定享受的产前假、产假、哺乳假，应作出勤对待。

·                     结论：

1）      认定劳动关系：工作证

2）      是否签合同

3）      如果没签合同，怎么补偿（1，相当于给2倍工资，2，补合同，3，如果辞退，再按照有合同补偿）

4）      如果是固定合同，怎么补偿（N+1）

5）      如果是无期合同，2倍

6）      孕妇怎么处理？

1、公司辞退孕妇的补偿情况标准是怎样？

答：发放工资到哺乳期满；按工作年限计算经济补偿金。

2、公司是否可以以我的考核和我是孕产妇不能胜任工作为由对我进行降职降级降薪处理？

答：不可以。

我们的工资分为基本工资（约占1/4)+岗位工资+绩效工资等。是否可能出现只要不降低我的基本工资就是合法的行为？

答：不合理。工资是包括了岗位工资和绩效工资。

3、如果公司依法破产，我是否有向集团主张赔偿的权利？

答：破产也可以主张权利，在破产财产中优先演戏偿。

4、如果可能需要诉诸法律，我应该准备哪些方面的举证？

答：存在劳动关系的证据最重要，此外，工资条、怀孕的证据、结婚证、准生证

也比较重要。（按照劳动法42条，不得解除三期【孕期、产期、哺乳期】妇女。那么如果一定要违反劳动法解除劳动关系，只能按照违反劳动法，按照第八十七条进行二倍赔偿，也就是3倍）

案例:

http://www.tianya.cn/publicforum/content/law/1/119373.shtml

案情：A公司辞退B孕妇（不考虑B可能存在的过错，假设A毫无道理毫无依据的辞退B孕妇）。

　　一审结果：判赔全额孕期工资、全额产期（晚育还加了15天）工资、75%的哺乳期工资，并以入职时间至三期届满为劳动合同关系存续期间计算在职时间，然后以该在职时间按照《劳动合同法》第八十七条判赔了赔偿金（即合法解除的补偿金的双倍）。一审不是我代理的。

　　二审A公司找到我，我想当然的以为，按照《劳动合同法》第八十七条的规定，劳动者可以选择要求继续履行，不要求继续履行的，应当仅支付双倍补偿即可，一审判决属适用法律错误。

你可以想象的出，一个库函数的异常信息不完整，对于他的用户来说，是多么不友好的事情。假设 MSDN 中 File.Open() 会抛出 IOException ，你的程序就很难想到很规矩的对 IOException 做了 catch ，然后提示用户检查相应位置的文件是否存在 / 被打开等。别指望 MSDN 的那些信息能够对终端用户有多大的帮助，太多不懂计算机的人在傻呆呆的握着鼠标了。再加上 MicroSoft 的提示信息本身就存在着“答非所问”，“莫名其妙”的事情，用户看到这些情况就更不知道怎么解决问题了。再加上自己的应用程序中会弹出一个个“蹩脚”的运行时错误的错误框，真的不是一个很如意的创作。

        但是，如果使用的是 Checked Exception ，这时候编译器会强迫你的外部接口的异常相当的完整，最起码可以做到比 MSDN 的异常类型齐整。

您还记得以前大多数开发人员是如何追求代码质量的吗。在那时，有技巧地放置 main() 方法被视为灵活且适当的测试方法。经历了漫长的道路以后，现在自动测试已经成为高质量代码开发的基本保证，对此我很感谢。但是这还不是我所要感谢的全部。Java™ 开发人员现在拥有很多通过代码度量、静态分析等方法来度量代码质量的工具。我们甚至已经设法将重构分类成一系列便利的模式！

要获得有关代码质量问题的答案，您可以访问由 Andrew Glover 主持的 Code Quality 论坛。

所有的这些新的工具使得确保代码质量比以前简单得多，不过您还需要知道如何使用它们。在这个系列中，我将重点阐述有关保证代码质量的一些有时看上去有点神秘的东西。除了带您一起熟悉有关代码质量保证的众多工具和技术之外，我还将为您说明：

• 定义并有效度量最影响质量的代码方面。
• 设定质量保证目标并照此规划您的开发过程。
• 确定哪个代码质量工具和技术可以满足您的需要。
• 实现最佳实践（清除不好的），使确保代码质量及早并经常地 成为开发实践中轻松且有效的方面。

在这个月，我将首先看看 Java 开发人员中最流行也是最容易的质量保证工具包：测试覆盖度量。

谨防上当

这是一个晚上鏖战后的早晨，大家都站在饮水机边上。开发人员和管理人员们了解到一些经过良好测试的类可以达到超过 90% 的覆盖率，正在高兴地互换着 NFL 风格的点心。团队的集体信心空前高涨。从远处可以听到 “放任地重构吧” 的声音，似乎缺陷已成为遥远的记忆，响应性也已微不足道。但是一个很小的反对声在说：

女士们，先生们，不要被覆盖报告所愚弄。

现在，不要误解我的意思：并不是说使用测试覆盖工具是愚蠢的。对单元测试范例，它是很重要的。不过更重要的是您如何理解所得到的信息。许多开发团队会在这儿犯第一个错。

高覆盖率只是表示执行了很多的代码，并不意味着这些代码被很好地 执行。如果您关注的是代码的质量，就必须精确地理解测试覆盖工具能做什么，不能做什么。然后您才能知道如何使用这些工具去获取有用的信息。而不是像许多开发人员那样，只是满足于高覆盖率。

回页首

测试覆盖度量

测试覆盖工具通常可以很容易地添加到确定的单元测试过程中，而且结果可靠。下载一个可用的工具，对您的 Ant 和 Maven 构建脚本作一些小的改动，您和您的同事就有了在饮水机边上谈论的一种新报告：测试覆盖报告。当 foo 和 bar 这样的程序包令人惊奇地显示高 覆盖率时，您可以得到不小的安慰。如果您相信至少您的部分代码可以保证是 “没有 BUG” 的，您会觉得很安心。但是这样做是一个错误。

存在不同类型的覆盖度量，但是绝大多数的工具会关注行覆盖，也叫做语句覆盖。此外，有些工具会报告分支覆盖。通过用一个测试工具执行代码库并捕获整个测试过程中与被 “触及” 的代码对应的数据，就可以获得测试覆盖度量。然后这些数据被合成为覆盖报告。在 Java 世界中，这个测试工具通常是 JUnit 以及名为 Cobertura、Emma 或 Clover 等的覆盖工具。

行覆盖只是指出代码的哪些行被执行。如果一个方法有 10 行代码，其中的 8 行在测试中被执行，那么这个方法的行覆盖率是 80%。这个过程在总体层次上也工作得很好：如果一个类有 100 行代码，其中的 45 行被触及，那么这个类的行覆盖率就是 45%。同样，如果一个代码库包含 10000 个非注释性的代码行，在特定的测试运行中有 3500 行被执行，那么这段代码的行覆盖率就是 35%。

报告分支覆盖 的工具试图度量决策点（比如包含逻辑 AND 或 OR 的条件块）的覆盖率。与行覆盖一样，如果在特定方法中有两个分支，并且两个分支在测试中都被覆盖，那么您可以说这个方法有 100% 的分支覆盖率。

问题是，这些度量有什么用？很明显，很容易获得所有这些信息，不过您需要知道如何使用它们。一些例子可以阐明我的观点。

回页首

代码覆盖在活动

我在清单 1 中创建了一个简单的类以具体表述类层次的概念。一个给定的类可以有一连串的父类，例如 Vector，它的父类是 AbstractList，AbstractList 的父类又是 AbstractCollection，AbstractCollection 的父类又是 Object：

												
														package com.vanward.adana.hierarchy;

import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;

public class Hierarchy {
  private Collection classes;
  private Class baseClass;

  public Hierarchy() {
    super();
    this.classes = new ArrayList();
  }

  public void addClass(final Class clzz){
    this.classes.add(clzz);
  }
  /**
   * @return an array of class names as Strings
   */
  public String[] getHierarchyClassNames(){
    final String[] names = new String[this.classes.size()];        
    int x = 0;
    for(Iterator iter = this.classes.iterator(); iter.hasNext();){
       Class clzz = (Class)iter.next();
       names[x++] = clzz.getName();
    }        
    return names;
  }

  public Class getBaseClass() {
    return baseClass;
  }

  public void setBaseClass(final Class baseClass) {
    this.baseClass = baseClass;
  }
}

												
										

正如您看到的，清单 1 中的 Hierarchy 类具有一个 baseClass 实例以及它的父类的集合。清单 2 中的 HierarchyBuilder 通过两个复制 buildHierarchy 的重载的 static 方法创建了 Hierarchy 类。

												
														package com.vanward.adana.hierarchy;

public class HierarchyBuilder {  

  private HierarchyBuilder() {
    super();		
  }

  public static Hierarchy buildHierarchy(final String clzzName) 
    throws ClassNotFoundException{
      final Class clzz = Class.forName(clzzName, false, 
          HierarchyBuilder.class.getClassLoader());        
      return buildHierarchy(clzz);
  }

  public static Hierarchy buildHierarchy(Class clzz){
    if(clzz == null){
      throw new RuntimeException("Class parameter can not be null");
    }

    final Hierarchy hier = new Hierarchy();
    hier.setBaseClass(clzz);

    final Class superclass = clzz.getSuperclass();

    if(superclass != 
      null && superclass.getName().equals("java.lang.Object")){
       return hier; 
    }else{      
       while((clzz.getSuperclass() != null) && 
          (!clzz.getSuperclass().getName().equals("java.lang.Object"))){
             clzz = clzz.getSuperclass();
             hier.addClass(clzz);
       }	        
       return hier;
    }
  }      
}

												
										

回页首

现在是测试时间！

有关测试覆盖的文章怎么能缺少测试案例呢？在清单 3 中，我定义了一个简单的有三个测试案例的 JUnit 测试类，它将试图执行 Hierarchy 类和 HierarchyBuilder 类：

												
														package test.com.vanward.adana.hierarchy;

import com.vanward.adana.hierarchy.Hierarchy;
import com.vanward.adana.hierarchy.HierarchyBuilder;
import junit.framework.TestCase;

public class HierarchyBuilderTest extends TestCase {
  
  public void testBuildHierarchyValueNotNull() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertNotNull("object was null", hier);
  }

  public void testBuildHierarchyName() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertEquals("should be junit.framework.Assert", 
       "junit.framework.Assert", 
         hier.getHierarchyClassNames()[1]);      
  }

  public void testBuildHierarchyNameAgain() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertEquals("should be junit.framework.TestCase", 
       "junit.framework.TestCase", 
         hier.getHierarchyClassNames()[0]);      
  }
 
}

												
										

因为我是一个狂热的测试人员，我自然希望运行一些覆盖测试。对于 Java 开发人员可用的代码覆盖工具中，我比较喜欢用 Cobertura，因为它的报告很友好。而且，Corbertura 是开放源码项目，它派生出了 JCoverage 项目的前身。

回页首

Cobertura 的报告

运行 Cobertura 这样的工具和运行您的 JUnit 测试一样简单，只是有一个用专门逻辑在测试时检查代码以报告覆盖率的中间步骤（这都是通过工具的 Ant 任务或 Maven 的目标完成的）。

正如您在图 1 中看到的，HierarchyBuilder 的覆盖报告说明部分代码没有 被执行。事实上，Cobertura 认为 HierarchyBuilder 的行覆盖率为 59%，分支覆盖率为 75%。

这样看来，我的第一次覆盖测试是失败的。首先，带有 String 参数的 buildHierarchy() 方法根本没有被测试。其次，另一个 buildHierarchy() 方法中的两个条件都没有被执行。有趣的是，所要关注的正是第二个没有被执行的 if 块。

因为我所需要做的只是增加一些测试案例，所以我并不担心这一点。一旦我到达了所关注的区域，我就可以很好地完成工作。注意我这儿的逻辑：我使用测试报告来了解什么没有 被测试。现在我已经可以选择使用这些数据来增强测试或者继续工作。在本例中，我准备增强我的测试，因为我还有一些重要的区域未覆盖。

Cobertura：第二轮

清单 4 是一个更新过的 JUnit 测试案例，增加了一些附加测试案例，以试图完全执行 HierarchyBuilder：

												
														package test.com.vanward.adana.hierarchy;

import com.vanward.adana.hierarchy.Hierarchy;
import com.vanward.adana.hierarchy.HierarchyBuilder;
import junit.framework.TestCase;

public class HierarchyBuilderTest extends TestCase {
  
  public void testBuildHierarchyValueNotNull() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertNotNull("object was null", hier);
  }

  public void testBuildHierarchyName() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertEquals("should be junit.framework.Assert", 
       "junit.framework.Assert", 
         hier.getHierarchyClassNames()[1]);      
  }

  public void testBuildHierarchyNameAgain() { zo       
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertEquals("should be junit.framework.TestCase", 
       "junit.framework.TestCase", 
         hier.getHierarchyClassNames()[0]);      
  }

  public void testBuildHierarchySize() {        
     Hierarchy hier = HierarchyBuilder.buildHierarchy(HierarchyBuilderTest.class);
     assertEquals("should be 2", 2, hier.getHierarchyClassNames().length);
  }

  public void testBuildHierarchyStrNotNull() throws Exception{
    Hierarchy hier = 
       HierarchyBuilder.
       buildHierarchy("test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
    assertNotNull("object was null", hier);
  }

  public void testBuildHierarchyStrName() throws Exception{        
    Hierarchy hier = 
       HierarchyBuilder.
       buildHierarchy("test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
    assertEquals("should be junit.framework.Assert", 
      "junit.framework.Assert",
        hier.getHierarchyClassNames()[1]);
  }

  public void testBuildHierarchyStrNameAgain() throws Exception{
    Hierarchy hier = 
       HierarchyBuilder.
       buildHierarchy("test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
    assertEquals("should be junit.framework.TestCase", 
      "junit.framework.TestCase",
        hier.getHierarchyClassNames()[0]);      
  }

  public void testBuildHierarchyStrSize() throws Exception{        
     Hierarchy hier = 
        HierarchyBuilder.
        buildHierarchy("test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
     assertEquals("should be 2", 2, hier.getHierarchyClassNames().length);        
  }

  public void testBuildHierarchyWithNull() {
     try{
       Class clzz = null;
       HierarchyBuilder.buildHierarchy(clzz);
       fail("RuntimeException not thrown");
     }catch(RuntimeException e){}
  }
}

												
										

当我使用新的测试案例再次执行测试覆盖过程时，我得到了如图 2 所示的更加完整的报告。现在，我覆盖了未测试的 buildHierarchy() 方法，也处理了另一个 buildHierarchy() 方法中的两个 if 块。然而，因为 HierarchyBuilder 的构造器是 private 类型的，所以我不能通过我的测试类测试它（我也不关心）。因此，我的行覆盖率仍然只有 88%。

正如您看到的，使用一个代码覆盖工具可以 揭露重要的没有相应测试案例的代码。重要的事情是，在阅读报告（特别 是覆盖率高的）时需要小心，它们也许隐含危险的信息。让我们看看两个例子，看看在高覆盖率后面隐藏着什么。

回页首

条件带来的麻烦

正如您已经知道的，代码中的许多变量可能有多种状态；此外，条件的存在使得执行有多条路径。在留意这些问题之后，我将在清单 5 中定义一个极其简单只有一个方法的类：

												
														package com.vanward.coverage.example01;

public class PathCoverage {

  public String pathExample(boolean condition){
    String value = null;
    if(condition){
      value = " " + condition + " ";
    }
    return value.trim();
  }
}

												
										

您是否发现了清单 5 中有一个隐藏的缺陷呢？如果没有，不要担心，我会在清单 6 中写一个测试案例来执行 pathExample() 方法并确保它正确地工作：

												
														package test.com.vanward.coverage.example01;

import junit.framework.TestCase;
import com.vanward.coverage.example01.PathCoverage;

public class PathCoverageTest extends TestCase {

  public final void testPathExample() {
    PathCoverage clzzUnderTst = new PathCoverage();
    String value = clzzUnderTst.pathExample(true);
    assertEquals("should be true", "true", value);
  }
}

												
										

我的测试案例正确运行，我的神奇的代码覆盖报告（如下面图 3 所示）使我看上去像个超级明星，测试覆盖率达到了 100%！

我想现在应该到饮水机边上去说了，但是等等，我不是怀疑代码中有什么缺陷呢？认真检查清单 5 会发现，如果 condition 为 false，那么第 13 行确实会抛出 NullPointerException。Yeesh，这儿发生了什么？

这表明行覆盖的确不能很好地指示测试的有效性。

回页首

路径的恐怖

在清单 7 中，我定义了另一个包含 indirect 的简单例子，它仍然有不能容忍的缺陷。请注意 branchIt() 方法中 if 条件的后半部分。（HiddenObject 类将在清单 8 中定义。）

												
														package com.vanward.coverage.example02;

import com.acme.someotherpackage.HiddenObject;

public class AnotherBranchCoverage {
   
  public void branchIt(int value){
    if((value > 100) || (HiddenObject.doWork() == 0)){
      this.dontDoIt();
    }else{
      this.doIt();
    }
  }                             

  private void dontDoIt(){
    //don't do something...
  }

  private void doIt(){
    //do something!
  }   
}

												
										

呀！清单 8 中的 HiddenObject 是有害的。与清单 7 中一样，调用 doWork() 方法会导致 RuntimeException：

												
														package com.acme.someotherpackage.HiddenObject;

public class HiddenObject {

  public static int doWork(){
    //return 1;
    throw new RuntimeException("surprise!");
  }
}

												
										

但是我的确可以通过一个良好的测试捕获这个异常！在清单 9 中，我编写了另一个好的测试，以图挽回我的超级明星光环：

												
														package test.com.vanward.coverage.example02;

import junit.framework.TestCase;
import com.vanward.coverage.example02.AnotherBranchCoverage;

public class AnotherBranchCoverageTest extends TestCase {
    
  public final void testBranchIt() {
    AnotherBranchCoverage clzzUnderTst = new AnotherBranchCoverage();
    clzzUnderTst.branchIt(101);
  }    
}

												
										

您对这个测试案例有什么想法？您也许会写出更多的测试案例，但是请设想一下清单 7 中不确定的条件有不止一个的缩短操作会如何。设想如果前半部分中的逻辑比简单的 int 比较更复杂，那么您 需要写多少测试案例才能满意？

仅仅给我数字

现在，对清单 7、8、9 的测试覆盖率的分析结果不再会使您感到惊讶。在图 4 的报告中显示我达到了 75% 的行覆盖率和 100% 的分支覆盖率。最重要的是，我执行了第 10 行！

从第一印象看，这让我骄傲。但是这个报告有什么误导吗？只是粗略地看一看报告中的数字，会导致您相信代码是经过良好测试的。基于这一点，您也许会认为出现缺陷的风险很低。这个报告并不能帮助您确定 or 缩短操作的后半部分是一个定时炸弹！

回页首

质量测试

我不止一次地说：您可以（而且应该）使用测试覆盖工具作为您的测试过程的一部分。但是不要被覆盖报告所愚弄。关于覆盖报告您需要了解的主要事情是，覆盖报告最好用来检查哪些代码没有经过 充分的测试。当您检查覆盖报告时，找出较低的值，并了解为什么特定的代码没有经过充分的测试。知道这些以后，开发人员、管理人员以及 QA 专业人员就可以在真正需要的地方使用测试覆盖工具。通常有下列三种情况：

• 估计修改已有代码所需的时间
• 评估代码质量
• 评定功能测试

现在我可以断定对测试覆盖报告的一些使用方法会将您引入歧途，下面这些最佳实践可以使得测试覆盖报告可以真正为您所用。

1. 估计修改已有代码所需的时间

对一个开发团队而言，针对代码编写测试案例自然可以增加集体的信心。与没有相应测试案例的代码相比，经过测试的代码更容易重构、维护和增强。测试案例因为暗示了代码在测试工作中是如何 工作的，所以还可以充当内行的文档。此外，如果被测试的代码发生改变，测试案例通常也会作相应的改变，这与诸如注释和 Javadoc 这样的静态代码文档不同。

在另一方面，没有经过相应测试的代码更难于理解和安全地 修改。因此，知道代码有没有被测试，并看看实际的测试覆盖数值，可以让开发人员和管理人员更准确地预知修改已有代码所需的时间。

再次回到饮水机边上，可以更好地阐明我的观点。

市场部的 Linda：“我们想让系统在用户完成一笔交易时做 x 工作。这需要多长时间。我们的用户需要尽快实现这一功能。”

管理人员 Jeff：“让我看看，这个代码是 Joe 在几个月前编写的，需要对业务层和 UI 做一些变动。Mary 也许可以在两天内完成这项工作。”

Linda：“Joe？他是谁？”

Jeff：“哦，Joe，因为他不知道自己在干什么，所以被我解雇了。”

情况似乎有点不妙，不是吗？尽管如此，Jeff 还是将任务分配给了 Mary，Mary 也认为能够在两天内完成工作 —— 确切地说，在看到代码之前她是这么认为的。

Mary：“Joe 写这些代码时是不是睡着了？这是我所见过的最差的代码。我甚至不能确认这是 Java 代码。除非推倒重来，要不我根本没法修改。”

情况对 “饮水机” 团队不妙，不是吗？但是我们假设，如果在这个不幸的事件的当初，Jeff 和 Mary 就拥有一份测试报告，那么情况会如何呢？当 Linda 要求实现新功能时，Jeff 做的第一件事就是检查以前生成的覆盖报告。注意到需要改动的软件包几乎没有被覆盖，然后他就会与 Mary 商量。

Jeff：“Joe 编写的这个代码很差，绝大多数没经过测试。您认为要支持 Linda 所说的功能需要多长时间？”

Mary：“这个代码很混乱。我甚至都不想看到它。为什么不让 Mark 来做呢？”

Jeff：“因为 Mark 不编写测试，刚被我解雇了。我需要您测试这个代码并作一些改动。告诉我您需要多长时间。”

Mary：“我至少需要两天编写测试，然后我会重构这个代码，增加新的功能。我想总共需要四天吧。”

正如他们所说的，知识的力量是强大的。开发人员可以在试图修改代码之前 使用覆盖报告来检查代码质量。同样，管理人员可以使用覆盖数据更好地估计开发人员实际所需的时间。

2. 评估代码质量

开发人员的测试可以降低代码中存在缺陷的风险，因此现在很多开发团队在新开发和更改代码的同时需要编写单元测试。然而正如前面所提到的 Mark 一样，并不总是在编码的同时进行单元测试，因而会导致低质量代码的出现。

监控覆盖报告可以帮助开发团队迅速找出不断增长的没有 相应测试的代码。例如，在一周开始时运行覆盖报告，显示项目中一个关键的软件包的覆盖率是 70%。如果几天后，覆盖率下降到了 60%，那么您可以推断：

• 软件包的代码行增加了，但是没有为新代码编写相应的测试（或者是新增加的测试不能有效地覆盖新代码）。
  
  
• 删除了测试案例。
  
  
• 上述两种情况都发生了。

能够监控事情的发展，无疑是件好事。定期地查阅报告使得设定目标（例如获得覆盖率、维护代码行的测试案例的比例等）并监控事情的发展变得更为容易。如果您发现测试没有如期编写，您可以提前采取一些行动，例如对开发人员进行培训、指导或帮助。与其让用户 “在使用中” 发现程序缺陷（这些缺陷本应该在几个月前通过简单的测试暴露出来），或者等到管理人员发现没有编写单元测试时再感到惊讶（和愤怒），还不如采取一些预防性的措施。

使用覆盖报告来确保正确的测试是一项伟大的实践。关键是要训练有素地完成这项工作。例如，使每晚生成并查阅覆盖报告成为连续累计 过程的一部分。

3. 评定功能测试

假设覆盖报告在指出没有经过 足够测试的代码部分方面非常有效，那么质量保证人员可以使用这些数据来评定与功能测试有关的关注区域。让我们回到 “饮水机” 团队来看看 QA 的负责人 Drew 是如何评价 Joe 的代码的：

Drew 对 Jeff 说：“我们为下一个版本编写了测试案例，我们注意到很多代码没有被覆盖。那好像是与股票交易有关的代码。”

Jeff：“哦，我们在这个领域有好些问题。如果我是一个赌徒的话，我会对这个功能区域给予特别的关注。Mary 正在对这个应用程序做一些其他的修改 —— 她在编写单元测试方面做得很好，但是这个代码也太差了点。”

Drew：“是的，我正在确定工作的资源和级别，看上去我没必要那么担心了，我估计我们的团队会对股票交易模块引起足够的关注。”

知识再次显示了其强大的力量。与其他软件生命周期中的风险承担者（例如 QA）配合，您可以利用覆盖报告所提供的信息来降低风险。在上面的场景中，也许 Jeff 可以为 Drew 的团队提供一个早期的不包含 Mary 的所有修改的版本。不过无论如何，Drew 的团队都应该关注应用程序的股票交易方面，与其他具有相应单元测试的代码相比，这个地方似乎存在更大的缺陷风险。

回页首

测试有什么好处

对单元测试范例而言，测试覆盖度量工具是一个有点奇怪的组成部分。对于一个已存在的有益的过程，覆盖度量可以增加其深度和精度。然而，您应该仔细地阅读代码覆盖报告。单独的高覆盖率并不能确保代码的质量。对于减少缺陷，代码的高覆盖并不是必要条件，尽管高覆盖的代码的确更少 有缺陷。

测试覆盖度量的窍门是使用覆盖报告找出未经 测试的代码，分别在微观和宏观两个级别。通过从顶层开始分析您的代码库，以及分析单个类的覆盖，可以促进深入的覆盖测试。一旦您能够综合这些原则，您和您的组织就可以在真正需要的地方使用覆盖度量工具，例如估计一个项目所需的时间，持续监控代码质量以及促进与 QA 的协作。

The Proxy pattern is an important and widely used design pattern in object-oriented programming. Do you ever use Proxy in Java since its introduction in JDK 1.3? A dynamic proxy class is a class that implements a list of interfaces specified at runtime. An implementation for the proxy's behavior can be provided at runtime through an InvocationHandler. So Proxy is an important class in Java's reflection package, and is widely used in many Java applications.

One limitation of Proxy is that it can only accept interfaces. In some circumstances, you need to apply the Proxy pattern not only to interfaces, but also to abstract classes, and even concrete classes.

This article introduces Dynamic Delegation, which can create delegation for both interfaces and classes at runtime.

Proxy Overview

In JDK 1.3, the Proxy class was added to java.lang.reflect. It can create a concrete class that implements all of the specified interfaces at runtime. The dynamically generated class redirects all of the method calls defined in the interfaces to an InvocationHandler.

Given two interfaces, Idel1 and Idel2, Proxy will create a IdelProxy class as the proxy of these two interfaces (I use IdelProxy as the generated proxy class name for convenience). Figure 1 shows this arrangement.

Figure 1. Class diagram of IdelProxy

Below is the related code snippet.

    Class clazz = Proxy.getProxyClass(
         Idel1.class.getClassLoader(), 
         new Class[] { Idel1.class, Idel2.class });

Delegation Versus Proxy

Proxy only works for interfaces. What if we need it to work for both classes and interfaces? The Dunamis project on java.net introduces Delegation as an alternative to Proxy. Delegation uses a different approach than Proxy.

Given a class named TestBean, the delegation class TestBeanDelegation's class diagram is shown in Figure 2.

Figure 2. Class diagram of TestBeanDelegation (click for full-size image)

TestBeanDelegation implements the Delegation interface and extends the TestBean class. It also contains references to TestBean and DelegationInvocationHandler. All of the method calls on TestBeanDelegation will be delegated to them.

Take getName() as an example. The chart in Figure 3 illustrates the sequence of the method call.

Figure 3. Sequence chart of TestBeanDelegation.getName() (click for full-size image)

The related pseudocode is:

//The delegation class is a sub-class of the class to be delegated
public class TestBeanDelegation extends TestBean
        implements Delegation {
    //The object to be delegated
    TestBean bean;
    //The invocation handler
    DelegationInvocationHandler handler;
    ...
    static Method m0 = null;
    ...

    static {
        ...
        try {
            m0 = TestBean.class.getMethod("getName",
                                 new Class[] {});
        } catch (Exception exception) {
        }
        ...
    }

    public TestBeanDelegation(Object bean) {
        this.bean = (TestBean)bean;
    }

    public String getName() {
        boolean goon = true;
        String ret = null;
        Throwable t = null;
        try {
            goon = handler.invokeBefore(bean,
                        m0, new Object[] {});
            if (goon)
                try {
                    ret = bean.getName();
                } catch (Throwable throwable) {
                    t = throwable;
                }
            if (t != null)
                ret = handler.invokeAfterException(bean,
                            m0, new Object[] {}, t);
            else
                ret = handler.invokeAfter(bean,
                            m0, new Object[] { name }, null);
            return ret;
        } catch (RuntimeException e) {
            throw e;
        } catch (Error e) {
            throw e;
        } catch (Throwable throwable) {
            throw new UndeclaredThrowableException(throwable);
        }
    }
}

An Introduction to Dynamic Delegation

Dynamic Delegation is based on the Jakarta Byte-Code Engineering Library (BCEL). It can analyze the existing class and generate a delegation class in byte code for an interface, abstract class, or even a concrete class at runtime.

The interface/class to be delegated should meet the following conditions:

• Dynamic Delegation can accept one class at most, but can accept multiple interfaces.

  This limitation is based on Java's single inheritance model. One Java class can have at most one superclass. Since the generated delegation class takes the given class as its superclass, it is illegal to specify more than one class. If no class specified, the default superclass is Object.

• The input class should have a default constructor with a public or protected modifier.

  The delegation class will call the superclass' default constructor in its own constructor.

• The input class cannot be final, and should be visible to the caller.

  The proxy class generated by Proxy is final. It will not be accepted by Dynamic Delegation.

• Dynamic Delegation cannot accept any class that implements the Delegation interface.

  Since it is already a delegation class, why would you need to delegate it again?

The generated delegation class has the following characteristics:

• It is generated on the fly and has no class file.
• It implements all of the given interfaces and extends the given class.
• It also implements the Delegation interface.
• It has a constructor that accepts an Object instance as a parameter.

DelegationGenerator is the main class of Dynamic Delegation. A client can use it to generate a delegation class/object for a specific class/interface/object. DelegationInvocationHandler is an interface defining all of the delegation behaviors and is expected to be implemented by the client's developer. The delegation object can use the _getInvocationHandler() and _setInvocationHandler() methods defined in Delegation to access the DelegationInvocationHandler instance in the delegation object.

Exercise 1. Create a Delegation Class for a Concrete Class

Suppose there is a concrete class named ConcreteClass:

//ConcreteClass.java
package org.jingle.util.dydelegation.sample;

public class ConcreteClass {
    public void hello() {
        System.out.println("Hello from ConcreteClass");
    }
    
    protected void hello2() {
        System.out.println("Hello again from ConcreteClass");
    }
}

The following code generates a delegation class for ConcreteClass.

//ConcreteClassTest.java
package org.jingle.util.dydelegation.sample;

import org.jingle.util.dydelegation.DelegationGenerator;

public class ConcreteClassTest {
    public static void main(String[] args) {
        Class clazz = DelegationGenerator
                .getDelegationClass(new Class[] { ConcreteClass.class });
        System.out.println("Delegation class name = " +
                            clazz.getName());
        System.out.println(
            ConcreteClass.class.isAssignableFrom(clazz));
    }
}

The output shows:

Delegation class name =
org.jingle.util.dydelegation.sample.ConcreteClass_Delegation_0
true

DelegationGenerator.getDelegationClass() accepts a class array as parameter and return a Java Class that extends/implements the given class/interfaces. By default, the generated delegation class is in the same package as the class to be delegated.

The delegation class can be instantiated as below:

//object to be delegated
Object obj = ...; 
//some concrete invocation handler instance
DelegationInvocationHandler h = ...; 

Constructor c = clazz.getConstructor(new Class[] { Object.class });
Object inst = c.newInstance(new Object[] {obj});
((Delegation) inst)._setInvocationHandler(h);

Exercise 2. Create a Delegation Class for an Abstract Class

DelegationGenerator can also generate a concrete delegation class for an abstract class.

//AbstractClass.java
package org.jingle.util.dydelegation.sample;

public abstract class AbstractClass {
    public abstract void wave();
}


//AbstractClassTest.java
package org.jingle.util.dydelegation.sample;

import java.lang.reflect.Modifier;

import org.jingle.util.dydelegation.DelegationGenerator;

public class AbstractClassTest {
    public static void main(String[] args) {
        Class clazz = DelegationGenerator
                .getDelegationClass(new Class[] { AbstractClass.class });
        System.out.println("Delegation class name = " +
            clazz.getName());
        System.out.println(
            Modifier.isAbstract(clazz.getModifiers()));
    }
}

Output:

Delegation class name = 
org.jingle.util.dydelegation.sample.AbstractClass_Delegation_0
false

The generated delegation class is a concrete class instead of an abstract class.

Exercise 3. Create a Delegation Class for Both a Class and Multiple Interfaces

DelegationGenerator.getDelegationClass() can accept a class and multiple interfaces simultaneously to generate a delegation class to delegate the given class and interfaces. Duplicate interfaces will be eliminated.

//Idel1.java
package org.jingle.util.dydelegation.sample.bean;

public interface Idel1 {
    public void idel1();
}


//Idel2.java
package org.jingle.util.dydelegation.sample.bean;

public interface Idel2 {
    public void idel2();
}


//ComplexClassTest.java
package org.jingle.util.dydelegation.sample;

import org.jingle.util.dydelegation.DelegationGenerator;
import org.jingle.util.dydelegation.sample.bean.Idel1;
import org.jingle.util.dydelegation.sample.bean.Idel2;

public class ComplexClassTest {
    public static void main(String[] args) {
        Class clazz = DelegationGenerator.getDelegationClass(new Class[] {
                ConcreteClass.class, Idel1.class, Idel2.class });
        System.out.println(
            Idel1.class.isAssignableFrom(clazz));
        System.out.println(
            Idel2.class.isAssignableFrom(clazz));
        System.out.println(
            ConcreteClass.class.isAssignableFrom(clazz));
    }
}

Output:

true
true
true

The generated delegation class extends the given class ConcreteClass and implements all of the given interfaces: Idel1 and Idel2.

Exercise 4. Create a Delegation Object for a Specific Object

DelegationGenerator can generate a delegation object directly, according to a specific object to be delegated.

// ConcreteClassTest2.java
package org.jingle.util.dydelegation.sample;

import java.lang.reflect.Method;

import org.jingle.util.dydelegation.DelegationGenerator;
import org.jingle.util.dydelegation.DelegationInvocationHandler;
import org.jingle.util.dydelegation.DummyInvocationHandler;

public class ConcreteClassTest2 {
    public static void main(String[] args) {
        ConcreteClass inst = new ConcreteClass();
        DelegationInvocationHandler handler =
            new SimpleHandler();
        ConcreteClass delegation = (ConcreteClass)
            DelegationGenerator.newDelegationInstance(inst, handler);
        delegation.hello();
        delegation.hello2();
        System.out.println(delegation.toString());
    }
}

class SimpleHandler extends DummyInvocationHandler {
    public boolean invokeBefore(Object bean,
                                Method method, Object[] args)
            throws Throwable {
        System.out.println("Interrupted by SimpleHandler");
        return super.invokeBefore(bean, method, args);
    }
}

Output:

Interrupted by SimpleHandler
Hello from ConcreteClass
Hello again from ConcreteClass
Interrupted by SimpleHandler
org.jingle.util.dydelegation.sample.ConcreteClass@ef5502

DummyInvocationHandler is a dummy implementation of DelegationInvocationHandler. It always returns true in invokeBefore(), returns the input result directly in invokeAfter(), and throws the input throwable directly in invokeAfterException(). The delegation object with DummyInvocationHandler has same behavior as the object to be delegated.

DelegationGenerator.newDelegationInstance() accepts an object and an DelegationInvocationHandler instance as parameters. It returns a delegation object to delegate the given object.

All of the methods called on the delegation object will be delegated to the DelegationInvocationHandler instance, except:

• Methods without a public modifier.
• Methods with a final modifier.
• Methods with a static modifier.
• Methods declared in the Object class, other than hashCode(), equals(), and toString().

Exercise 5. Create Delegation Object for the Object of a Java Core Class

Did you ever want to delegate an object of an existing Java core class? Delegate it as usual.

//DateTest.java
package org.jingle.util.dydelegation.sample;

import java.lang.reflect.Method;
import java.util.Date;

import org.jingle.util.dydelegation.DelegationGenerator;
import org.jingle.util.dydelegation.DelegationInvocationHandler;
import org.jingle.util.dydelegation.DummyInvocationHandler;

public class DateTest {
    public static void main(String[] args) {
        Date date = new Date();
        DelegationInvocationHandler handler = 
            new DateClassHandler();
        Date delegation = (Date) DelegationGenerator
                .newDelegationInstance(date, handler);
        System.out.println("Delegation class = " +
            delegation.getClass().getName());
        System.out.println("True date = " +
            date.getTime());
        System.out.println("Delegation date = " +
            delegation.getTime());
    }
}

class DateClassHandler extends DummyInvocationHandler {
    public Object invokeAfter(Object bean,
                    Method method, Object[] args,
                    Object result) throws Throwable {
        if (method.getName().equals("getTime")) {
            return new Long(((Long)result).longValue() - 1000);
        }
        return super.invokeAfter(bean, method, args, result);
    }
}

Output:

Delegation class = org.jingle.util.dydelegation.Date_Delegation_0
True date = 1099380377665
Delegation date = 1099380376665

When creating a delegation class for a Java core class, the delegation class will not be in the same package as the Java core class, because the Java security model does not allow a user-defined ClassLoader to define a class in a package starting with java.

DateClassHandler catches the getTime() method call in invokeAfter(), and makes the return value 1000 less than the normal return value.

Advanced Usage

Exercise 6. Simulate Proxy Behavior

Can Dynamic Delegation do what Proxy does? Absolutely! Dynamic Delegation covers the functions of Proxy. Given a proper delegation handler, it can simulate the behavior of a Java Proxy.

// ProxyTest.java
package org.jingle.util.dydelegation.sample;

import java.lang.reflect.Method;

import org.jingle.util.dydelegation.DelegationGenerator;
import org.jingle.util.dydelegation.DelegationInvocationHandler;
import org.jingle.util.dydelegation.DummyInvocationHandler;
import org.jingle.util.dydelegation.sample.bean.Idel1;
import org.jingle.util.dydelegation.sample.bean.Idel2;

public class ProxyTest {
    public static void main(String[] args) {
        DelegationInvocationHandler handler = new ProxyHandler();
        Object delegation =
            DelegationGenerator.newDelegationInstance(null,
                new Class[] { Idel1.class, Idel2.class },
                null, handler);
        ((Idel1) delegation).idel1();
        ((Idel2) delegation).idel2();
    }
}

class ProxyHandler extends DummyInvocationHandler {
    public boolean invokeBefore(Object bean,
            Method method, Object[] args)
            throws Throwable {
        return false;
    }

    public Object invokeAfter(Object bean, 
            Method method, Object[] args,
            Object result) throws Throwable {
        String name = method.getName();
        if (name.equals("idel1"))
            System.out.println("Hello from idel1");
        else if (name.equals("idel2"))
            System.out.println("Hello from idel2");
        return super.invokeAfter(bean, method, args, result);
    }
}

Output:

Hello from idel1
Hello from idel2

ProxyHandler returns false in invokeBefore(), which means all of the method calls on the delegation object will not be delegated to the original object. It uses invokeAfter() to define the delegation behavior as being what Proxy does.

DelegationGenerator.newDelegationInstance() has another version. It contains four arguments:

• The Object to be delegated.

  This can be null. If it is not null, it must be an instance of all of the given classes and interfaces.

• An array of Class to be delegated.

  This can contain multiple interfaces and, at most, one class.

• Delegation class name.

  If null, a system-generated name will be provided.

• A DelegationInvocationHandler instance, which is used to define the delegation's behavior.

From the output, we can see that the delegation object is an instance of both Idel1 and Idel2. Its behavior is just what is defined in the handler.

Exercise 7. Partial Delegation

Until now, we've delegated all of the functions of the specific object. How about just delegating part of the object's functions?

//MyDate.java
package org.jingle.util.dydelegation.sample.bean;

import java.util.Date;

public class MyDate extends Date implements Idel1, Idel2 {
    public void idel1() {
    }

    public void idel2() {
    }
}


// MyDateTest.java
package org.jingle.util.dydelegation.sample;

import java.util.Date;

import org.jingle.util.dydelegation.DelegationGenerator;
import org.jingle.util.dydelegation.DelegationInvocationHandler;
import org.jingle.util.dydelegation.DummyInvocationHandler;
import org.jingle.util.dydelegation.sample.bean.Idel1;
import org.jingle.util.dydelegation.sample.bean.Idel2;
import org.jingle.util.dydelegation.sample.bean.MyDate;

public class MyDateTest {
    public static void main(String[] args) {
        MyDate inst = new MyDate();
        DelegationInvocationHandler handler =
            new DummyInvocationHandler();
        Object delegation = 
            DelegationGenerator.newDelegationInstance(inst,
                new Class[] { Idel1.class, Idel2.class },
                null, handler);
        System.out.println(delegation instanceof Idel1);
        System.out.println(delegation instanceof Idel2);
        System.out.println(delegation instanceof Date);
    }
}

Output:

true
true
false

MyDate extends Date and implements the Idel1 and Idel2 interfaces. DelegationGenerator.newDelegationInstance() uses a MyDate instance as the object instance to be delegated, and limits the delegation scope in Idel1 and Idel2. In other words, the generated delegation object is an instance of Idel1 and Idel2, but not an instance of Date.

Conclusion

The Dunamis project introduces Dynamic Delegation to extend the function of the Java Proxy reflection utility. It can generate delegation for both classes and interfaces at runtime. This article introduces Dynamic Delegation in brief with simple examples. In the real world, Dynamic Delegation can be used in many areas, such as mock objects in unit testing, Java GUI MVC framework, and more.

Reference

• Dunamis project: dunamis.dev.java.net
• Download sample code for this article: sample code
• BCEL: jakarta.apache.org/bcel/index.html

Lu Jian is a senior Java architect/developer with four years of Java development experience.

Exercise 1. Create a Delegation Class for a Concrete Class

Suppose there is a concrete class named ConcreteClass:

//ConcreteClass.java
package org.jingle.util.dydelegation.sample;

public class ConcreteClass {
    public void hello() {
        System.out.println("Hello from ConcreteClass");
    }
    
    protected void hello2() {
        System.out.println("Hello again from ConcreteClass");
    }
}

The following code generates a delegation class for ConcreteClass.

//ConcreteClassTest.java
package org.jingle.util.dydelegation.sample;

import org.jingle.util.dydelegation.DelegationGenerator;

public class ConcreteClassTest {
    public static void main(String[] args) {
        Class clazz = DelegationGenerator
                .getDelegationClass(new Class[] { ConcreteClass.class });
        System.out.println("Delegation class name = " +
                            clazz.getName());
        System.out.println(
            ConcreteClass.class.isAssignableFrom(clazz));
    }
}

The output shows:

Delegation class name =
org.jingle.util.dydelegation.sample.ConcreteClass_Delegation_0
true

DelegationGenerator.getDelegationClass() accepts a class array as parameter and return a Java Class that extends/implements the given class/interfaces. By default, the generated delegation class is in the same package as the class to be delegated.

The delegation class can be instantiated as below:

//object to be delegated
Object obj = ...; 
//some concrete invocation handler instance
DelegationInvocationHandler h = ...; 

Constructor c = clazz.getConstructor(new Class[] { Object.class });
Object inst = c.newInstance(new Object[] {obj});
((Delegation) inst)._setInvocationHandler(h);

Exercise 2. Create a Delegation Class for an Abstract Class

DelegationGenerator can also generate a concrete delegation class for an abstract class.

//AbstractClass.java
package org.jingle.util.dydelegation.sample;

public abstract class AbstractClass {
    public abstract void wave();
}


//AbstractClassTest.java
package org.jingle.util.dydelegation.sample;

import java.lang.reflect.Modifier;

import org.jingle.util.dydelegation.DelegationGenerator;

public class AbstractClassTest {
    public static void main(String[] args) {
        Class clazz = DelegationGenerator
                .getDelegationClass(new Class[] { AbstractClass.class });
        System.out.println("Delegation class name = " +
            clazz.getName());
        System.out.println(
            Modifier.isAbstract(clazz.getModifiers()));
    }
}

Output:

Delegation class name = 
org.jingle.util.dydelegation.sample.AbstractClass_Delegation_0
false

The generated delegation class is a concrete class instead of an abstract class.

Exercise 3. Create a Delegation Class for Both a Class and Multiple Interfaces

DelegationGenerator.getDelegationClass() can accept a class and multiple interfaces simultaneously to generate a delegation class to delegate the given class and interfaces. Duplicate interfaces will be eliminated.

//Idel1.java
package org.jingle.util.dydelegation.sample.bean;

public interface Idel1 {
    public void idel1();
}


//Idel2.java
package org.jingle.util.dydelegation.sample.bean;

public interface Idel2 {
    public void idel2();
}


//ComplexClassTest.java
package org.jingle.util.dydelegation.sample;

import org.jingle.util.dydelegation.DelegationGenerator;
import org.jingle.util.dydelegation.sample.bean.Idel1;
import org.jingle.util.dydelegation.sample.bean.Idel2;

public class ComplexClassTest {
    public static void main(String[] args) {
        Class clazz = DelegationGenerator.getDelegationClass(new Class[] {
                ConcreteClass.class, Idel1.class, Idel2.class });
        System.out.println(
            Idel1.class.isAssignableFrom(clazz));
        System.out.println(
            Idel2.class.isAssignableFrom(clazz));
        System.out.println(
            ConcreteClass.class.isAssignableFrom(clazz));
    }
}

Output:

true
true
true

The generated delegation class extends the given class ConcreteClass and implements all of the given interfaces: Idel1 and Idel2.

Exercise 4. Create a Delegation Object for a Specific Object

DelegationGenerator can generate a delegation object directly, according to a specific object to be delegated.

// ConcreteClassTest2.java
package org.jingle.util.dydelegation.sample;

import java.lang.reflect.Method;

import org.jingle.util.dydelegation.DelegationGenerator;
import org.jingle.util.dydelegation.DelegationInvocationHandler;
import org.jingle.util.dydelegation.DummyInvocationHandler;

public class ConcreteClassTest2 {
    public static void main(String[] args) {
        ConcreteClass inst = new ConcreteClass();
        DelegationInvocationHandler handler =
            new SimpleHandler();
        ConcreteClass delegation = (ConcreteClass)
            DelegationGenerator.newDelegationInstance(inst, handler);
        delegation.hello();
        delegation.hello2();
        System.out.println(delegation.toString());
    }
}

class SimpleHandler extends DummyInvocationHandler {
    public boolean invokeBefore(Object bean,
                                Method method, Object[] args)
            throws Throwable {
        System.out.println("Interrupted by SimpleHandler");
        return super.invokeBefore(bean, method, args);
    }
}

Output:

Interrupted by SimpleHandler
Hello from ConcreteClass
Hello again from ConcreteClass
Interrupted by SimpleHandler
org.jingle.util.dydelegation.sample.ConcreteClass@ef5502

DummyInvocationHandler is a dummy implementation of DelegationInvocationHandler. It always returns true in invokeBefore(), returns the input result directly in invokeAfter(), and throws the input throwable directly in invokeAfterException(). The delegation object with DummyInvocationHandler has same behavior as the object to be delegated.

DelegationGenerator.newDelegationInstance() accepts an object and an DelegationInvocationHandler instance as parameters. It returns a delegation object to delegate the given object.

All of the methods called on the delegation object will be delegated to the DelegationInvocationHandler instance, except:

• Methods without a public modifier.
• Methods with a final modifier.
• Methods with a static modifier.
• Methods declared in the Object class, other than hashCode(), equals(), and toString().

1)本质上，软件开发中一切代码都需要重构。经过单元测试覆盖的代码可以让我拥有信心去重构。我也不知道还有什么其他办法能够让我获得如此的信心。如果没有信心，那么我就不太敢经常的重构，这也必然影响代码的品质。

2) Due to the nature of unit-tests (emphasize: unit), it is impossible to test a "badly-smelling" code. In order to be able to unit-test your code, it has to be cleaner, and better designed: short, focused methods, writing to Interfaces, lously coupled etc.
2）由于单元测试的自然特性（注意是单元测试），无法对具有“坏味道”的代码进行单元测试。而为了能够顺利的对你的代码进行单元测试，那么你的代码就会逐渐的变得更加清晰、设计更加完善：代码短小、专注方法、针对接口编程、降低耦合等。

I think, this might not have been something that was foreseen initially but discovered later. My guess is, initially, people just wanted to make computer do what it is best for - repetitive work (in this case - testing) and have code test the application, not humans. But as a "byproduct" they noticed that testing requires design improvement, too. When they discovered it, somebody smart-enough had an idea - if it is so, why not write tests first? Design is supposed to come before the implementation and if tests affect design, it makes sense to write them before the implementation, too.

我想，也许单元测试的提倡者事前也未曾会预料到它能够带来这已经证实了的益处。我想，刚开始人们也就只是希望发挥计算机的特点，让它完成重复性的工作（这里是指测试），而不再需要人去进行测试。但是他们发现了“副产品”―测试需要更好的设计。接着，他们中的杰出者提出了一个全新的想法－既然如此，那何不事先写好测试呢？设计是应该在代码实现之前的，而如果测试可以影响设计，那么何不也将测试在代码实现之前进行编写呢？

And the TDD started...

于是TDD开始了…….。


====================================

http://www.theserverside.com/news/thread.tss?thread_id=32394#160294

I think I agree with some of the objections raised with TDD, but the problem seems more with how people use it than a basic flaw in the concept. The 2 primary objections raised are:
1. There is a lot of test-centric coding with less focus on ensuring overall business requirement is fulfilled.
2. Developers seem to think that having run the product through the Unit tests ensures that the product is well-tested and production ready.

我对TDD所引起的问题非常的同意，但是问题更在于人们如何解决它，而不是仅停留在基本的观念上。TDD主要引起的问题是：
1、 存在着太多的“以测试为中心”的代码，而更少的关注于整体的业务需求。
2、开发者好像开始认为跑遍单元测试就可以保证产品的可测试和产品的质量。



All that TDD should be expected to do is run a sanity check at the end of a new build to ensure that the contracts that each unit of code is supposed to fulfill have not been broken. You still need to go through your entire QA cycle to ensure you have a functional product. So, the automated unit tests are just additional checks and do not replace QA. But, unfortunately I have seen situations where people believe that once they have a proper build and unit tested they can reduce the time they spend in QA. Not really true!!! It just ensures that if the unit tests were written properly, the quality of the code reaching QA will be a little better.

所有的TDD能做的是在整个项目构建结束之后完成一个检查工作，保证原有的单元之间的契约没用被打破。在项目构建完成后，还需要一个质量保证(quality assurance)的过程，以保证整个项目的功能。也就是说自动化测试只是一个附加的检查，而不是对质量保证的全盘替代。但不幸的是，我看到的人们却非如此。他们认为一旦单元测试成功，那么就可以减少QA上面的时间。但事实真的不是这样的。单元测试所能做倒的也仅在于单元测试已经很好的编写完成，代码的质量更容易达到QA的标准。