代码可测性度量工具Testability explorer

可测性维度包括架构设计、代码2个层面。

  架构层面拟从2个角度出发积累1)将日常qa碰到可测性及架构建议沉淀下来2）和架构师探讨sei atam架构评审方法

  代码层面可测性可单独用testability explorer度量，也可使用hudson上testability explorer插件度量。

Google内部广泛使用的testability explorer静态分析java bytecode并按规则计算类的可测性分数，将类划分为优秀、可容忍、需要调整3个等级，默认分数分别为<=50,<=100; >100（见CommandLineConfig.java）。

      Testability explorer逐行递归分析判断是否不可注入、全局变量，如果是则分值加1,直到递归深度达到Depth。本质上，testability explorer驱动研发养成符合依赖注入风格的编码习惯。Google内部也组合testability explorer等多个工具一起提升代码质量。

可测性判断用途:

1)    加入到持续集成hudson/continuum内，成为进度度量指示器

2)    研发根据可测性判断是否需要重构

更多参考：http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/

http://misko.hevery.com/category/testability/

   可测性和代码高效间需要做平衡，可测性不能做：

1)     need work的类就直接让研发重构代码

2)     直接找bug

很多的事实证明，测试领域没有银弹。测试需要借助工具在合适场合辅助提高测试效率，最核心的还是人的判断力。

部署编译

确认机器已经搭建好maven2的环境。

设置环境变量（本机eclipse路径，更多看http://code.google.com/p/testability-explorer/wiki/HowToContribute）：

ECLIPSE_LAUNCHER_JAR=D:\eclipse-java-ganymede-SR1-win32\plugins\org.eclipse.osgi_3.4.2.R34x_v20080826-1230.jar 

（否则提示错误：

Caused by: D:\project\google_testability_explorer\eclipse-plugin\build.xml:13: Java returned: 1
        at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)）

取出源代码：svn checkout http://testability-explorer.googlecode.com/svn/trunk/ testability-explorer

cd testability-explorer

执行安装部署：mvn install

调整被测工程的pom.xml

在project节内加入：

<reporting>

   <plugins>

       <plugin>

       <groupId>com.google.testability-explorer</groupId>

                  <artifactId>maven-testability-plugin</artifactId>       

       <version>1.3.4-SNAPSHOT</version>

     </plugin>

   </plugins>

</reporting>

具体的版本号根据：D:\project\google_testability_explorer\maven-testability-plugin\target生成的jar定。

在　C:\Documents and Settings\jianzhao.liangjz\.m2\repository\com\google\testability-explorer\maven-testability-plugin\1.3.4-SNAPSHOT有maven-testability-plugin-1.3.4-SNAPSHOT.jar

从D:\project\google_testability_explorer\maven-testability-plugin\src\main\java\com\google\maven\TestabilityExplorerMojo.java 找到目标testability。

执行maven目标分析代码可测性

D:\project\morgan\trunk\member.service.china> mvn clean install

D:\project\morgan\trunk\member.service.china>mvn com.google.testability-explorer:maven-testability-plugin:1.3.4-SNAPSHOT:testability

或者看：　http://code.google.com/p/testability-explorer/wiki/HowToMakeARelease

在顶级工程上执行上述命令也可，但是site目录会仅生成在各个子工程目录下。

结果如下：

Issues that cause the most untestable classes

Cost: 6,376

Classcom.alibaba.china.biz.dal.EncryptPtpis hard to test because:

It is expensive to construct an instance of the class, and every test will need to call a constructor.

These static initializers will need to be run once, when the class is loaded.^{Why is it bad?}

Instead of initializing this state statically, try initializing a fresh copy in each instance. Creating new objects in Java is cheap, and this static state can't be cleaned up between tests.

Cost: 6,254

Classcom.alibaba.china.biz.common.security.BlowfishEncrypteris hard to test because:

It is expensive to construct an instance of the class, and every test will need to call a constructor.

These static initializers will need to be run once, when the class is loaded.^{Why is it bad?}

Instead of initializing this state statically, try initializing a fresh copy in each instance. Creating new objects in Java is cheap, and this static state can't be cleaned up between tests.

Cost: 4,982

Classcom.alibaba.china.member.internal.security.Authenticationis hard to test because:

It is expensive to construct an instance of the class, and every test will need to call a constructor