HTTP Status 500 

java.lang.NullPointerException 	
org.apache.struts2.impl.StrutsActionProxy.getErrorMessage(StrutsActionProxy.java:69) 	
com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:185) 

• 表示层(presentation)－窗口、报表-
• 业务逻辑层(business logic)－管理业务过程的任务和规则。它又可以细分为领域对象层（代表领域概念）和服务层（提供数据库交互、安全性、打印报表）。
• 存储层(storage)－持久化存储机制。如数据库服务器等。
  

• 支持聚合度更高的模型定义，使模型的定义可以集中在领域过程的定义，而不是图形界面上。
• 允许将模型和用户界面并行开发。
• 使用户界面的需求变化对领域层所造成的影响最小化。
• 允许建立与一个现有的领域层对象相连接的新视图，同时不影响领域层。
• 允许一个模型同时有多个视图，例如使用SVG和表格。
• 允许模型层独立于用户界面层执行。
  

为了编译和运行SWT程序，我们有两种选择：1- 使用Eclipse SDK；2- 下载单独的SWT二进制文件和源文件。

随Eclipse SDK，我们可以在它的plugins目录下找到SWT的二进制文件，通常的目录名称是：org.eclipse.swt.win32_xxxx，后缀是版本号，在这个目录下有os和ws两个子目录，内容分别是SWT的JNI库和swt.jar。

如果不是使用Eclipse来开发，或者需要SWT的源文件，那么需要下载单独的SWT二进制和源文件包，在下面的地址可以找到：

http://mirror.pacific.net.au/eclipse/eclipse/downloads/drops/R-3.0.1-200409161125/swt-3.0.1-win32.zip

这个zip文件解包以后包含JNI库（一些DLL）和swt.jar，以及swtsrc.zip，这个swtsrc就是我们SWT的源文件了，包括C和Java的源代码。

为了运行SWT程序，我们需要首先编译我们SWT的代码，这个时候需要告诉编译器swt.jar的位置；编译成功以后，我们除了指明classpath包含swt.jar之外，需要在命令行告诉java.exe另一个参数，那就是java.library.path，看上去大概是这个样子：

java -cp %SWT_HOME%\swt.jar SimplestSWT -Djava.library.path=%SWT_HOME%

如果你使用的是Eclipse SDK 3.1M5a或者更新的版本，你可以直接右键.java文件选择Run As -> SWT Application，则不用在命令行写那么长的参数了。

比较有意思的是，我们可以在eclipse.org的SWT下载页面看到目前SWT支持的平台：

       Windows 98/ME/2000/XP
       Windows CE (ARM PocketPC)
       Windows CE (ARM PocketPC, J2ME profile)
       Linux (x86/Motif)
       Linux (x86/GTK 2)
       Linux (AMD 64/GTK 2)
       Solaris 8 (SPARC/Motif)
       QNX (x86/Photon)
       AIX (PPC/Motif)
       HP-UX (HP9000/Motif)      
       Mac OSX (Mac/Carbon)
呵呵，支持的平台虽然有限，不过还是蛮多了。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/tiney/archive/2008/09/12/2916785.aspx

证书在公钥加密应用中的作用是保证公钥在某些可信的机构发布，其在协议SSL、电子交易协议SET等方面有重要的应用。图1显示了一个最简单的证书应用方法：

证书的应用步骤是：

（1） A把自己的公钥PKA送到CA(Certificate Authority)；

（2） CA用自己的私钥和A的公钥生成A的证书，证书内包括CA的数字签名。签名对象包括需要在证书中说明的内容，比如A的公钥、时间戳、序列号等，为了简化这里不妨假设证书中只有三项内容：A的公钥PKA、时间戳TIME1、序列号IDA。那么CA发送给A的简单证书凭证可表达为：CertA=Eca[TIME1,IDA,PKA]；

（3） B同样把自己的公钥PKB送到CA；

（4） B得到CA发布的证书CertB;

（5） A告知B证书CertA；

（6） B告知A证书CertB。

A、B各自得到对方证书后，利用从CA得到的公钥(在CA的自签证书中)验证彼此对方的证书是否有效，如果有效，那么就得到了彼此的公钥。利用对方的公钥，可以加密数据，也可以用来验证对方的数字签名。

本文为了方便说明，并没有使用从CA获得的证书，而是通信双方各自产生自签证书，也就是说图1的A和B并没有经过CA，不过前提是A和B之间是互相拥有对方的证书。

证书的内容和意义如表1所示（这里以通用X .509证书格式为例）。

对证书的详细定义及其应用相关的各种协议，这里不加详细说明，详细细节请查看RFC2450、RFC2510、RFC2511、RFC2527、RFC2528、RFC2559、RFC2560、RFC2585、RFC2587等文档。

个人或机构可以从信任的证书分发机构申请得到证书，比如说，可以从http://ca.pku.edu.cn 得到一个属于个人的证书。这里可以利用J2SDK的安全工具keytool手工产生自签证书，所谓自签证书是指证书中的“Subject Name”和“Issuer Name”相同的证书。

下面产生一个自签证书。安装完J2SDK（这里用的是J2SDK1.4）后，在J2SDK安装目录的bin目录下，有一个keytool的可执行程序。利用keytool产生自签证书的步骤如下：

第一步，用-genkey命令选项，产生公私密钥对。在控制台界面输入：keytool -genkey -alias testkeypair -keyalg RSA -keysize 1024 -sigalg MD5withRSA。这里的-alias表示使用这对公私密钥产生新的keystore入口的别名(keystore是用来存放管理密钥对和证书链的，缺省位置是在使用者主目录下，以.keystore为名的隐藏文件，当然也可指定某个路径存放.keystore文件)；-keyalg是产生公私钥对所用的算法，这里是RSA；-keysize定义密钥的长度；-sigalg是签名算法，选择MD5withRSA，即用RSA签名，然后用MD5哈希算法摘要。接下来，系统会提示进行一些输入：

输入keystore密码： abc123 您的名字与姓氏是什么？ [Unknown]： Li 您的组织单位名称是什么？ [Unknown]： InfosecLab 您的组织名称是什么？ [Unknown]： InfosecLab Group 您所在的城市或区域名称是什么？ [Unknown]： Beijing 您所在的州或省份名称是什么？ [Unknown]： Beijing 该单位的两字母国家代码是什么 [Unknown]： CN CN=Li, OU=InfosecLab, O=InfosecLab Group, L=Beijing, ST=Beijing, C=CN 正确吗？ [否]： y 输入<testkeypair>的主密码 (如果和 keystore 密码相同，按回车）：

第二步，产生自签证书，输入以下命令：

keytool -selfcert -alias testkeypair -dname "CN=Li, OU=InfosecLab, O=InfosecLab Group, L=Beijing, ST=Beijing, C=CN" 输入keystore密码： abc123

第三步，导出自签证书，由上面两步产生的证书，已经存放在以“testkeypair”为别名的keystore入口了，如果使用其文件，必须导出证书。输入:

keytool -export -rfc -alias testkeypair -file mycert.crt 输入keystore密码： abc123 保存在文件中的认证 <mycert.crt>

这样，就得到了一个自签的证书mycert.crt。注意，选项rfc是把证书输出为RFC1421定义的、用Base64最终编码的格式。

Java为安全应用提供了丰富的API，J2SDK1.4 的JSSE (JavaTM Secure Socket Extension) 包括javax.security.certificate包，并且提供对证书的操作方法。而对证书的读操作，只用java.security.cert. CertificateFactory和java.security.cert.X509Certificate就可以了。下面是读取证书内容的部分代码：

import javax.swing.*; import java.awt.*; import java.awt.event.*; import javax.swing.table.*; import java.security.cert.CertificateFactory; import java.security.cert.X509Certificate; import java.io.*; public class CARead extends JPanel { private String CA_Name; private String CA_ItemData[][] = new String[9][2]; private String[] columnNames = {"证书字段标记","内容" }; public CARead(String CertName) { CA_Name=CertName; /* 三个Panel用来显示证书内容*/ JTabbedPane tabbedPane = new JTabbedPane(); JPanel panelNormal = new JPanel(); tabbedPane.addTab("普通信息", panelNormal); JPanel panelAll=new JPanel(); panelAll.setLayout(new BorderLayout()); tabbedPane.addTab("所有信息",panelAll); JPanel panelBase64=new JPanel(); panelBase64.setLayout(new BorderLayout()); tabbedPane.addTab("Base64编码信息",panelBase64); /* 读取证书常规信息 */ Read_Normal(panelNormal); /* 读取证书文件字符串表示内容 */ Read_Bin(panelAll); /* 读取证原始Base64编码形式的证书文件 */ Read_Raw(panelBase64); tabbedPane.setSelectedIndex(0); setLayout(new GridLayout(1, 1)); add(tabbedPane); } /*以下是定义的Read_Normal()，Read_Bin(),Read_Raw()以及main() 这里省略... */ }

定义证书信息的读取函数如下：

private int Read_Normal(JPanel panel){ String Field; try{ CertificateFactory certificate_factory=CertificateFactory.getInstance("X.509"); FileInputStream file_inputstream=new FileInputStream(CA_Name); X509Certificate x509certificate=(X509Certificate)certificate_factory.generateCertificate (file_inputstream); Field=x509certificate.getType(); CA_ItemData[0][0]="类型"; CA_ItemData[0][1]=Field; Field=Integer.toString(x509certificate.getVersion()); CA_ItemData[1][0]="版本"; CA_ItemData[1][1]=Field; Field=x509certificate.getSubjectDN().getName(); CA_ItemData[2][0]="标题"; CA_ItemData[2][1]=Field; /* 以下类似，这里省略 Field=x509certificate.getNotBefore().toString();得到开始有效日期 Field=x509certificate. getNotAfter().toString();得到截止日期 Field=x509certificate.getSerialNumber().toString(16);得到序列号 Field=x509certificate.getIssuerDN().getName();得到发行者名 Field=x509certificate.getSigAlgName();得到签名算法 Field=x509certificate.getPublicKey().getAlgorithm();得到公钥算法 */ file_inputstream.close(); final JTable table = new JTable(CA_ItemData, columnNames); TableColumn tc=null; tc = table.getColumnModel().getColumn(1); tc.setPreferredWidth(600); panel.add(table); }catch(Exception exception){ exception.printStackTrace(); return -1; } return 0; }

如果以字符串形式读取证书，加入下面Read_Bin这个函数。其中CertificateFactory.generateCertificate() 这个函数可以从证书标准编码(RFC1421定义)中解出可读信息。Read_Bin函数代码如下：

private int Read_Bin(JPanel panel){ try{ FileInputStream file_inputstream=new FileInputStream(CA_Name); DataInputStream data_inputstream=new DataInputStream(file_inputstream); CertificateFactory certificatefactory=CertificateFactory.getInstance("X.509"); byte[] bytes=new byte[data_inputstream.available()]; data_inputstream.readFully(bytes); ByteArrayInputStream bais=new ByteArrayInputStream(bytes); JEditorPane Cert_EditorPane; Cert_EditorPane=new JEditorPane(); while(bais.available()>0){ X509Certificate Cert=(X509Certificate)certificatefactory.generateCertificate(bais); Cert_EditorPane.setText(Cert_EditorPane.getText()+Cert.toString()); } Cert_EditorPane.disable(); JScrollPane edit_scroll=new JScrollPane(Cert_EditorPane); panel.add(edit_scroll); file_inputstream.close(); data_inputstream.close(); }catch( Exception exception){ exception.printStackTrace(); return -1; } return 0; }

如果要得到原始证书编码后的信息，则可用如下代码：

private int Read_Raw(JPanel panel){ try{ JEditorPane Cert_EditorPane=new JEditorPane(); String CertText=null; File inputFile = new File(CA_Name); FileReader in = new FileReader(inputFile); char[] buf=new char[2000]; int len=in.read(buf,0,2000); for(int i=1;i<len;i++) { CertText=CertText+buf[i]; } in.close(); Cert_EditorPane.setText(CertText); Cert_EditorPane.disable(); JScrollPane edit_scroll=new JScrollPane(Cert_EditorPane); panel.add(edit_scroll); }catch( Exception exception){ exception.printStackTrace(); return -1; } return 0; }

最后用这个小程序看一看刚才生成的证书mycert.crt内容，把文件名写入main()中：

public static void main(String[] args) { JFrame frame = new JFrame("证书阅读器"); frame.addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent e) {System.exit(0);} }); frame.getContentPane().add(new CARead("mycert.crt"),BorderLayout.CENTER); frame.setSize(700, 425); frame.setVisible(true); }

证书mycert.crt的内容显示如图2所示，所有信息和Base64的显示内容，这里不再列举。

现在已经读取了证书的一些内容，那么怎样使用证书呢？我们可以假设A和B要共享一个绝密的文件F，B信任并拥有A的证书，也就是说B拥有A的公钥。那么A通过A和B共知的加密算法(对称密钥算法，比如DES算法)先加密文件F，然后对加密后的F进行签名和散列摘要(比如MD5算法，目的是保证文件的完整性)，然后把F发送到B。B收到文件后，先用A的证书中的公钥验证签名，然后再用通过共知的加密算法解密，就可以得到原文件了。这里使用的数字签名，可以保证B得到的文件，就是A的，A不能否认其不拥有文件F，因为只有A拥有可以让A的公钥验证其签名的私钥，同时这里使用DES算法加密，使得文件有保密性。

使用DES算法的加密解密函数类似，这里不对加密算法做进一步讨论，详细请看J2SDK的JSE部分内容，加密签名、解密验证文件结构见图3。



图3 加密签名、解密验证文件结构图

加密函数中的desKeyData存放DES加密密钥，如果要在程序中指定，可以设置为：

static byte[] desKeyData = { (byte)0x01, (byte)0x02, (byte)0x03, (byte)0x04, (byte)0x05, (byte)0x06, (byte)0x07, (byte)0x08 };

加密函数写成：

public static void crypt(byte[] cipherText,String outFileName){ try{ DESKeySpec desKeySpec = new DESKeySpec(desKeyData); SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES"); SecretKey secretKey = keyFactory.generateSecret(desKeySpec); Cipher cdes = Cipher.getInstance("DES"); cdes.init(Cipher.ENCRYPT_MODE, secretKey); byte[] ct = cdes.doFinal(cipherText); try{ FileOutputStream out=new FileOutputStream(outFileName); out.write(ct); out.close(); }catch(IOException e){ e.printStackTrace(); } }catch (Exception e){ e.printStackTrace(); } }

其中ct就是加密后的内容,outFileName保存加密后文件的文件名。把cdes.init(Cipher.ENCRYPT_MODE, secretKey)换成cdes.init(Cipher.DECRYPT_MODE, secretKey)就是解密文件了。

文件加密后就要对文件签名，保证A发送到B的文件不可伪造。下面是用存放在.keystore中的私钥进行签名的函数，签名使用的摘要算法是MD5。其中sigText是被签名内容的输入数组，outFileName是保存签名后输出文件的名称，KeyPassword是读取Keystore使用的密码，KeyStorePath是存放.keystore文件的路径，函数代码如下：

public static void sig(byte[] sigText, String outFileName,String KeyPassword,String KeyStorePath){ char[] kpass; int i; try{ KeyStore ks = KeyStore.getInstance("JKS"); FileInputStream ksfis = new FileInputStream(KeyStorePath); BufferedInputStream ksbufin = new BufferedInputStream(ksfis); kpass=new char[KeyPassword.length()]; for(i=0;i<KeyPassword.length();i++) kpass[i]=KeyPassword.charAt(i); ks.load(ksbufin, kpass); PrivateKey priv = (PrivateKey) ks.getKey(KeystoreAlias,kpass ); Signature rsa=Signature.getInstance("MD5withRSA"); rsa.initSign(priv); rsa.update(sigText); byte[] sig=rsa.sign(); System.out.println("sig is done"); try{ FileOutputStream out=new FileOutputStream(outFileName); out.write(sig); out.close(); }catch(IOException e){ e.printStackTrace(); } }catch(Exception e){ e.printStackTrace(); } }

验证签名需要存放签名文件和被签名的文件以及证书，其中，updateData存放被签名文件的内容，sigedText存放得到的签名内容，CertName是证书名。验证签名代码如下：

public static void veriSig(byte[] updateData, byte[] sigedText){ try{ CertificateFactory certificatefactory=CertificateFactory.getInstance("X.509"); FileInputStream fin=new FileInputStream(CertName); X509Certificate certificate=(X509Certificate)certificatefactory.generateCertificate(fin); PublicKey pub = certificate.getPublicKey(); Signature rsa=Signature.getInstance("MD5withRSA"); rsa.initVerify(pub); rsa.update(updateData); boolean verifies=rsa.verify(sigedText); System.out.println("verified "+verifies); if(verifies){ System.out.println("Verify is done!"); }else{ System.out.println("verify is not successful"); } }catch(Exception e){ e.printStackTrace(); } }

可以用keytool产生两个自签的签名证书，或者到某个CA去申请两个证书。用Java编写加密和验证程序，上述例子只是一个非常简单的证书应用，实际协议对证书的使用(比如SSL)要比这个复杂多了。

The basic format of the command for creating a JAR file is:

jar cf jar-file input-file(s)

Let's look at the options and arguments used in this command:

• The c option indicates that you want to create a JAR file.
• The f option indicates that you want the output to go to a file rather than to stdout.
• jar-file is the name that you want the resulting JAR file to have. You can use any filename for a JAR file. By convention, JAR filenames are given a .jar extension, though this is not required.
• The input-file(s) argument is a space-delimited list of one or more files that you want to be placed in your JAR file. The input-file(s) argument can contain the wildcard * symbol. If any of the "input-files" are directories, the contents of those directories are added to the JAR archive recursively.

The c and f options can appear in either order, but there must not be any space between them.

This command will generate a compressed JAR file and place it in the current directory. The command will also generate a default manifest file for the JAR archive.

You can add any of these additional options to the cf options of the basic command:

jar cmf existing-manifest jar-file input-file(s)
            

In version 1.1, the JAR-file format supports only ASCII filenames. Version 1.2 adds support for UTF8-encoded names.

Let's look at an example. The JDK demos include a simple TicTacToe applet. This demo contains a bytecode class file, audio files, and images all housed in a directory called TicTacToe having this structure:

The audio and images subdirectories contain sound files and GIF images used by the applet.

To package this demo into a single JAR file named TicTacToe.jar, you would run this command from inside the TicTacToe directory:

jar cvf TicTacToe.jar TicTacToe.class audio images

The audio and images arguments represent directories, so the Jar tool will recursively place them and their contents in the JAR file. The generated JAR file TicTacToe.jar will be placed in the current directory. Because the command used the v option for verbose output, you'd see something similar to this output when you run the command:

adding: TicTacToe.class
            (in=3825) (out=2222) (deflated 41%)
            adding: audio/ (in=0) (out=0) (stored 0%)
            adding: audio/beep.au
            (in=4032) (out=3572) (deflated 11%)
            adding: audio/ding.au
            (in=2566) (out=2055) (deflated 19%)
            adding: audio/return.au
            (in=6558) (out=4401) (deflated 32%)
            adding: audio/yahoo1.au
            (in=7834) (out=6985) (deflated 10%)
            adding: audio/yahoo2.au
            (in=7463) (out=4607) (deflated 38%)
            adding: images/ (in=0) (out=0) (stored 0%)
            adding: images/cross.gif
            (in=157) (out=160) (deflated -1%)
            adding: images/not.gif
            (in=158) (out=161) (deflated -1%)
            

You can see from this output that the JAR file TicTacToe.jar is compressed. The Jar tool compresses files by default. You can turn off the compression feature by using the 0 (zero) option, so that the command would look like:

jar cvf0 TicTacToe.jar TicTacToe.class audio images

You might want to avoid compression, for example, to increase the speed with which a JAR file could be loaded by a browser. Uncompressed JAR files can generally be loaded more quickly than compressed files because the need to decompress the files during loading is eliminated. However, there's a tradeoff in that download time over a network may be longer for larger, uncompressed files.

The Jar tool will accept arguments that use the wildcard * symbol. As long as there weren't any unwanted files in the TicTacToe directory, you could have used this alternative command to construct the JAR file:

jar cvf TicTacToe.jar *

Though the verbose output doesn't indicate it, the Jar tool automatically adds a manifest file to the JAR archive with pathname META-INF/MANIFEST.MF. See the Understanding the Manifest section for information about manifest files.

In the above example, the files in the archive retained their relative pathnames and directory structure. The Jar tool in version 1.2 of the Java Development Kit provides the -C option that you can use to create a JAR file in which the relative paths of the archived files are not preserved. It's modeled after GZIP's -C option.

As an example, suppose you wanted put audio files and gif images used by the TicTacToe demo into a JAR file, and that you wanted all the files to be on the top level, with no directory hierarchy. You could accomplish that by issuing this command from the parent directory of the images and audio directories:

jar cf ImageAudio.jar -C images * -C audio *

The -C images part of this command directs the Jar tool to go to the images directory, and the * following -C images directs the Jar tool to archive all the contents of that directory. The -C audio * part of the command then does the same with the audio directory. The resulting JAR file would have this table of contents:

META-INF/MANIFEST.MF
            cross.gif
            not.gif
            beep.au
            ding.au
            return.au
            yahoo1.au
            yahoo2.au
            

By contrast, suppose that you used a command that didn't employ the -C option:

jar cf ImageAudio.jar images audio

The resulting JAR file would have this table of contents:

META-INF/MANIFEST.MF
            images/cross.gif
            images/not.gif
            audio/beep.au
            audio/ding.au
            audio/return.au
            audio/yahoo1.au
            audio/yahoo2.au
            

JIT是just in time,即时编译技术。使用该技术，能够加速java程序的执行速度。下面，就对该技术做个简单的讲解。

首先，我们大家都知道，通常javac将程序源代码编译，转换成java字节码，JVM通过解释字节码将其翻译成对应的机器指令，逐条读入，逐条解释翻译。很显然，经过解释执行，其执行速度必然会比可执行的二进制字节码程序慢。为了提高执行速度，引入了JIT技术。

在运行时JIT会把翻译过的机器码保存起来，已备下次使用，因此从理论上来说，采用该JIT技术可以，可以接近以前纯编译技术。下面我看看，JIT的工作过程。

JIT 编译过程

当JIT编译启用时（默认是启用的），JVM读入.class文件解释后，将其发给JIT编译器。JIT编译器将字节码编译成本机机器代码，下图展示了该过程。

什么是JIT？

JIT是just in time,即时编译技术。使用该技术，能够加速java程序的执行速度。下面，就对该技术做个简单的讲解。

首先，我们大家都知道，通常javac将程序源代码编译，转换成java字节码，JVM通过解释字节码将其翻译成对应的机器指令，逐条读入，逐条解释翻译。很显然，经过解释执行，其执行速度必然会比可执行的二进制字节码程序慢。为了提高执行速度，引入了JIT技术。

在运行时JIT会把翻译过的机器码保存起来，已备下次使用，因此从理论上来说，采用该JIT技术可以，可以接近以前纯编译技术。下面我看看，JIT的工作过程。

JIT 编译过程

当JIT编译启用时（默认是启用的），JVM读入.class文件解释后，将其发给JIT编译器。JIT编译器将字节码编译成本机机器代码，下图展示了该过程。

通过上面的解释，我们了解了JIT的工作原理及过程，同样也发现了个问题，由于JIT对每条字节码都进行编译，造成了编译过程负担过重。为了避免这种情况，当前的JIT只对经常执行的字节码进行编译，如循环等。

需要说明的是，JIT并不总是奏效，不能期望JIT一定能够加速你代码执行的速度，更糟糕的是她有可能降低代码的执行速度。这取决于你的代码结构，当然很多情况下我们还是能够如愿以偿的。

     有了上面那些信息对于系统的调优会有很大帮助。这里提供有几篇文章供参考：获取、介绍，简单入门，使用JProfiler解决实际问题。这几篇文章基本介绍了常见东西了，下面说点心得。

1. JProfiler监控是要消耗系统资源的，所以一般情况下不要用于性能测试时候的监控。
   
2. 如果要用于相对大压力情况下，可以有选择的打开监控项，不用所有都打开。主要有两个，一个是内存监控，打开的情况下可以查找内存分配热点。一个是CPU监控，打开的情况下可以查看CPU使用热点。
   如图所示，红笔标注部分。如果两个都关闭的话，还是可以跑一定压力的，同时还可以监控对象数量。
   
3. 个人认为最好用的（也是用的最多的）是查询当前的对象的数量。数量监控很重要，如果你使用了单例，那么你只会看到有一个对象存在，如果多了就说明程序有问题了。同样，如果应用进行一系列操作，检查一下该销毁的对象是否还继续存在，如果没有释放，就得考虑是否存在内存溢出了。
   
4. JProfiler还提供了一个比较好的检查内存溢出得工具。他可以查找某个对象的引用情况，即：当你发现某个该释放掉的对象没有释放，就可以看一下哪个实例在引用它，找到了根即找到了溢出点。
   具体操作如下：在 “Memory Views”界面中右键选择你要监控的对象，选择第一项“Take Heap Snapshot for Selection”，选择完成后会进入“Heap Walker”界面，界面下面提供几个功能，选择“References”即可 。如图：
   
   
5. JProfiler提供不同的观察粒度，提供对类的监控、对包的监控、对J2EE组件的监控，同时过滤器也比较好用，直接定位你关注的包或类即可。
   
6. JProfiler的监控可能与应用之间存在一定时间差，所以有些时候需要等待刷新，才能显示正确系统情况。

       在中间件应用服务器的整体调优中，有关于等待队列、执行线程，EJB池以及数据库连接池和Statement Cache方面的调优，这些都属于系统参数方面的调优，本文主要从另外一个角度，也就是从应用的角度来解决中间件应用服务器的内存泄露问题，从这个角度来提高系统的稳定性和性能。

项目背景

问题描述

某个大型项目（Use Case用例超过300个），在项目上线后，其Web应用服务器经常宕机。表现为：

1. 应用服务器内存长期不合理占用，内存经常处于高位占用，很难回收到低位；

2. 应用服务器极为不稳定，几乎每两天重新启动一次，有时甚至每天重新启动一次；

3. 应用服务器经常做Full GC(Garbage Collection)，而且时间很长，大约需要30-40秒，应用服务器在做Full GC的时候是不响应客户的交易请求的，非常影响系统性能。

Web应用服务器的物理部署

      一台Unix服务器（4CPU，8G Memory）来部署本Web应用程序；Web应用程序部署在中间件应用服务器上；部署了一个节点（Node），只配置一个应用服务器实例（Instance），没有做Cluster部署。

Web应用服务器启动脚本中的内存参数

MEM_ARGS="-XX:MaxPermSize=128m -XX:MaxNewSize=512m -Xms3096m -Xmx3096m -XX:+Printetails -Xloggc:./inwebapp1/gc.$$"

可以看出目前生产系统中Web应用服务器的内存分配为3G Memory。

Web应用服务器的重要部署参数

参数名称	参数值	参数解释
kernel.default(Thread Count)	120	执行线程数目，是并发处理能力的重要参数
Session Timeout	240分钟（4小时）	HttpSession会话超时

分析

分析方法

内存长期占用并导致系统不稳定一般有两种可能：

1. 对象被大量创建而且被缓存，在旧的对象释放前又有大量新的对象被创建使得内存长期高位占用。

• 表现为：内存不断被消耗、在高位时也很难回归到低位，有大量的对象在不断的创建，经过很长时间后又被回收。例如：在HttpSession中保存了大量的分页查询数据，而HttpSession的会话超时时间设置过长（例如：1天），那么在旧的对象释放前又有大量新的对象在第二天产生。
• 解决办法：对共享的对象可以采用池机制进行缓存，避免各自创建；缓存的临时对象应该及时释放；另一种办法是扩大系统的内存容量。

2. 另一种情况就是内存泄漏问题

• 表现为：内存回收低位点不断升高（以每次内存回收的最低点连成一条直线，那么它是一条上升线）；内存回收的频率也越来越高，内存占用也越来越高，最终出现"Out of Memory Exception"的系统异常。
• 解决办法：定位那些有内存泄漏的类或对象并修改完善这些类以避免内存泄漏。方法是：经过一段时间的测试、监控，如果某个类的对象数目屡创新高，即使在JVM Full GC后仍然数目降不下来，这些对象基本上是属于内存泄漏的对象了。

问题定位

这里请看5月份 Web应用服务器的内存回收图形：

《注意：5月18日早上10点重新启动了Web服务器，5月20日早上又重新启动了Web服务器。》

• 在Web应用重要部署参数中，我们知道：Session的超时时间为4个小时，我们在监控平台也观测到：在18日晚上10点左右所有的会话都过期了，从图形一中也能看出18日晚上确实系统的内存有回收到40%（就象股票的高位跳水）；
• 从图形一（5月18日）中我们也能看到Full GC回收后的内存占用率走势（红色曲线），上午基本平滑上升到20%（内存占用率），中午开始上升到30%，下午上升到40%
• 从图形二（5月19日）中我们也能看到Full GC回收后的内存占用率走势（红色曲线），上午又上升到了60%，到下午上升到了70%。
• 从黄色曲线（GC花费的时间，以秒为单位），Full GC的频率也在增快，时间耗费也越来越长，在图形一中基本高位在20秒左右，到19日基本都是30-40秒之间了。

 图形一 5月18日


图二

通过上述分析，我们基本定位到了Web应用服务器的内存在高位长期占用的原因了：是内存泄露！并且正是由于这个原因导致系统不稳定、响应客户请求越来越慢的。

解决方法

方法如下：

• 我们从图形二中发现，在8.95(将近9点钟)到9.66（将近9点40）期间有几次Full GC，但是有内存泄漏，从占用率40%上升到50%左右，泄漏了大约10%的内存，约300M；
• 我们在自己搭建的Web应用服务器平台（应用软件版本和生产版本一致）做这一阶段相同的查询交易；表明对同一个黑盒（Web应用）施加同样的刺激（相同的操作过程和查询交易）以期重现现象；
• 我们使用Jprofiler工具对Web应用服务器的内存进行实时监控；
• 做完这些交易后，用户退出系统，并等待Web应用服务器的HttpSession超时（我们这里设置为15分钟）；
• 我们对Web应用服务器做了两次强制性的内存回收操作。

发现如下：

图三

如图三所示，内存经过HttpSession超时后，并强制gc后，仍然有大量的对象没有释放。例如：gov.gdlt.taxcore.comm.security.MenuNode，仍然有807个实例没有释放。

我们继续追溯发现，这些MenuNode首先存放在一个ArrayList对象中，然后发现这个ArrayList对象又是存放在WHsessionAttrVO对象的Map中，WHsessionAttrVO 对象又是存放在ExternalSessionManager的staic Map中（名称为sessionMap），如图四所示。

图四

我们发现gov.gdlt.taxcore.taxevent.xtgl.comm.WHsessionAttrVO中保存了EJBSessionId信息(登录用户的唯一标志，由用户id+登录时间戳组成，每天都不同)和一个HashMap，这个HashMap中的内容有：

• ArrayList: 内有MenuTreeNodes（菜单树节点）
• HashMap: 内有操作人员代码信息
• CurrentVersion:当前版本号
• CurrentTime:当前系统时间

WHsessionAttrVO这个对象的最终存放在ExternalSessionManager的static Map sessionMap中，由于ExternalSessionManager是一个全局的单实例，不会释放，所以它的成员变量sessionMap中的数据也不会释放，而Map中的Key值为EJBSessionId，每天登录的用户EJBSessionId都不同，就造成了每天的登录信息（包括菜单信息）都保存在sessionMap中不会被释放，最终造成了内存的泄漏。

图五

如上图所示：WHsessionAttrsVO对象中除了有一个String对象（内容是EJBSessionId），还有一个HashMap对象。

图六

如上图所示，这个HashMap中的内容主要有menuTreeNodes为key，value为ArrayList的对象和以czrydminfo为key，value为HashMap对象的数据。

图七

如上图所示：menuTreeNodes为key，value为ArrayList对象中包含的对象有许多的MenuNode对象，封装的都是用户的菜单节点。

图八

如上图所示，最顶层（Root）的初始对象为一个ExternalSessionManager对象，其中的一个成员变量为static (静态的)，名称为：sessionMap，这个对象是singleton方式的，全局只有一个。

初步估量

我们从图形一和图形二中可以看出，每天应用服务器损失大约40%的内存，大约1G左右。

从图形四可以看出，当前用户（Id=24400001129）有807个菜单项（每个菜单项为一个MenuNode 对象实例，图形四中的这个实例的size为592 Byte），这些菜单数据和用户基本登录信息（czrydmInfo HashMap）也都存放在WHsessionAttrVO对象中，当前这个WHsessionAttrVO对象的size为457K。

我们做如下估算：

假设平均每天有4千人（估计值，这个数值仅仅是5月19日峰值的1/2左右）登录系统（有重复登录的现象，例如：上午登录一次，中午退出系统，下午登录一次），以平均每人占用200K（估计值，是用户id=24400001129 的Size的1/2左右）来计算，一天泄漏的内存约800M，比较符合目前内存泄漏的情况。当然，这种估计仍然需要经过实践的检验，方法是：当这次发现的内存泄漏问题解决后看系统是否还有其它内存泄漏问题。

方案

ExternalSessionManager类是当初某某软件商设计的用来解决Web服务器负载均衡的模块，这个类主要用来保存客户的基本登录信息（包括会话的EJBSessionId），以维护多个Web服务器之间的会话信息一致。

改进方案有两种：

• 从架构设计方面改进

  实现Web层的负载均衡有很多标准的实现方式。例如：采用负载均衡设备(硬件或软件)来实现。

  如果采用新的Web层的负载均衡方式，那么就可以去掉ExternalSessionManager这个类了。

• 从应用实现方面改进

  保留当前的Web层的负载均衡设计机制，仅仅从应用实现方面解决内存泄漏问题，首先菜单信息不应该保存在ExternalSessionManager中。其次，增加对ExternalSessionManager类中用户会话登录信息的清除，有几种方式可以选择：

  • 被动方式，当HttpSession会话超时（或过期）被Web应用服务器回收时清除相应的ExternalSessionManager中的过期会话登录信息。
  • 主动方式，可以采用任务定时清理每天的过期会话登录信息或线程轮询清理。
  • 采用新的会话登录信息存储方式，ExternalSessionManager的sessionMap中的key值不再以EJBSessionId作为键值，而是以用户id（EJBSessionId的前11位）代替。由于用户id每天都是一样的，所以不会造成内存泄漏。保存得登录信息也不再包含菜单节点信息，而只是登录基本信息。最多也只是保存整个系统所有的用户id及其基本登录信息（大约每个用户的登录信息只有1.5K左右，而目前这个系统的营业网点用户为1万左右，所以大约只占用Web服务器15M内存）。

实施情况

采用的方案：某某软件商采用了新的会话登录信息存贮方案，即:ExternalSessionManager的成员变量sessionMap中不再保存用户菜单信息，只保存基本的登录信息；存储方式采用用户id（11位）作为键值（key）来保留用户基本登录信息。

基本分析：由于基本登录信息只有1K左右，而目前内网登录的用户总数也只有8887个，所以只保存了大约10M-15M的信息在内存，占用量很小，并且不会有内存泄漏。用户菜单信息保存在session中，如果用户退出时点击logout页面，那么应用服务器可以很快地释放这部分内存；如果用户直接关闭窗口，那么保存在session中的菜单信息只有等会话超时后才会由系统清除并回收内存。

监控状况：

图九

如图九所示，ExternalSessionManager中只保留了简单的登录信息（Map中保存了WHsessionAttrVO对象），包括：当前版本(currentversion)，操作人员代码基本信息（czrydmInfo），当前时间（currenttime）。

图十

如图十所示，这个登录用户的基本信息只有1368 bytes，大约1.3K

图十一

如图十一所示，一共有两个用户（相同的用户id）登录系统，当一个用户使用logout页面退出时，保留在session中的菜单信息(MenuNode)立刻释放了，所以Difference一栏减少了806个菜单项。

图十二

如图十二所示，当另外一个会话超时后，应用服务器回收了整个会话的菜单信息（MenuNode），图上已经没有MenuNode对象了。并且由于是同一个用户登录，所以保留在ExternalSessionManager成员变量sessionMap中的对象WHsessionAttrVO只有一个(id=24400001129)，而没有产生多个，没有因为多次登录而产生多个对象的后果，避免了内存泄漏问题的出现，解决了前期定位的内存泄漏问题。

图十三

如图十三所示，经过gc内存回收后，发现内存回收比较稳定，基本都回收到了最低点，也证明了内存没有泄露。

结论与建议：从测试情况看，解决了前期定位的内存泄漏问题。

生产系统实施后的监控与分析

经过调优后，我们发现：在2005年6月2日晚9点40左右重新部署、启动了Web应用服务器（采用了新的调优方案）。经过几天的监控运行，发现Web应用服务器目前运行基本稳定，目前没有出现新的内存泄漏问题，下列图示说明了这一点

图十四 2005年6月2日

如图十四所示，6月2日晚21.7（21点42分）重新启动应用服务器，内存占用很少，大约为15%（请看红色曲线），每次GC消耗的时间也很短，大约在5秒以内（请看黄色曲线）。

图十五 2005年6月3日周五

如图十五所示，在6月3日周五的整个工作日内，内存的回收基本到位，回收位置控制在20%-30%之间，也就是在600M-900M之间（请看红色曲线的最低点），始终可以回收2G的内存供应用程序使用，每次GC的时间最高不超过20秒，Full GC平均在10秒左右，时间消耗比较短（请看黄色曲线）。

图十六2005年6月5日周日

如图十六所示，在周日休息日期间，Web应用服务器全天只做了大约4次Full GC（黄色曲线中的小山峰），时间都在10秒以内；大的Full GC后，内存只占用10%，内存回收很彻底。

图十七 2005年6月6日周一

如图十七所示，在周一工作日期间，内存回收还是不错的，基本可以回收到30%（见红色曲线的最低点），即：占用900M内存空间，剩余2G的内存空间；Full GC的时间大部分控制在20秒以内，平均15秒（见黄色曲线）。

图十八 2005年6月7日周二

如图十八所示，在6月7日周二早上，大约8:30左右，Web应用服务器作了一次Full GC，用了10秒的时间，把内存回收到了10%的位置，为后续的使用腾出了90%的内存空间。内存回收仍然比较彻底，说明基本没有内存泄漏问题。

经过这几天的监控分析，我们可以看出：

• Web应用服务器的内存使用已经比较合理，内存在工作日的占用在20%至30%之间，约1G的内存占用，有2G的内存空间富裕；而在空闲时间（周日，每天的凌晨等）内存可以回收到10%，有90%的内存空间富裕；
• Web应用服务器的Full GC的次数明显减少了并且每次Full GC占用的时间也很少，基本控制在10-20秒之间，有的甚至在10秒以内，明显改善了内网应用服务器内存的使用；
• 从6月2日重新部署之后，Web应用服务器没有出现宕机重启的现象。

总结

 通过本文，我们可以看到，内存的泄露将会导致服务器的宕机，系统性能就更别说了。对于系统内存泄露问题应该从服务器GC日志方面进行早诊断，使用工具早确认并提出解决方案，排除内存泄露问题，提高系统性能，以规避项目风险。

public class JarFileInfoRead {
 public static void main (String args[])
  throws IOException {
  String jarpath="d://temp//test.jar";
  JarFile jarFile = new JarFile(jarpath);
  Enumeration enu = jarFile.entries();
  while (enu.hasMoreElements()) {
      process(enu.nextElement());
  }
}

private static void process(Object obj) {
  JarEntry entry = (JarEntry)obj;
  String name = entry.getName();
  long size = entry.getSize();
  long compressedSize = entry.getCompressedSize();
  System.out.println(name + "\t" + size + "\t" + compressedSize);
}
}

Listing A包含了一个简单示例的代码，这个示例会说明常用JTable的行为。用户能够更改JTable的布局、拖放它的栏，或者通过拖动标题的分隔线来改变其大小。

这些列被保存在一个String数组里：

1 Object[][] data  =
2 {
3 { " Apples " ,  new  Integer( 5 ), " 5.00 " } ,
4           { " Oranges " ,  new  Integer( 3 ), " 6.00 " } ,
5           { " Pears " ,  new  Integer( 2 ), " 4.00 " } ,
6           { " Grapes " ,  new  Integer( 3 ), " 2.00 " } ,
7 } ;

JTable是使用data和columnNames构成的：
JTable table = new JTable(data, columnNames);

查看JTable

JTable的高度和宽度按照下面的方法来设定：
table.setPreferredScrollableViewportSize(new Dimension(300, 80));

如果JTable的一个列或者JTable窗口自身的大小被重新确定，那么其他列会被相应的缩小或者放大，以适应新的窗口。使用setAutoResizeMode()方法就能够控制这种行为：

表格的缺省值

单元格内方格坐标线的缺省颜色是Color.gray。要更改这些方格坐标线的颜色，就要用到：

各个单元格的高度将等于行的高度减去行间的距离。

在缺省情况下，内容的前景颜色和背景颜色的选择都是由Swing的所见即所得的实现来确定的。你可以使用下面的方法来更改选择的颜色：

列的宽度

JTable组件有几个控制表格特性的类和接口。TableColumn会不断追踪列的宽度，并负责列大小的调整，包括最大和最小宽度。

TableColumnModel管理着TableColumns的集合以及列的选择。要设置某个列的宽度，就要为表格列的模型设置一个参照。然后，取得想要的TableColumn并调用其setPreferredWidth()方法：

标题

JtableHeader会处理JTable标题的显示。你可以细分JtableHeader以获得自定义的布局。例如，如果你的应用程序需要一个跨越多个列的标题，那么只用简单地细分JtableHeader并将它集成到你的JTable里就行了。

你可以通过为当前JTable的JtableHeader设置一个参照或者调用其setReorderingAllowed()方法，来指定标题的重新排序是否被允许：

选择模式

在缺省状况下，当用户在JTable里选择一个单元格的时候，整个行都被选中了。有多种方法能够让用户自定义选择的方式。利用ListSelectionModel接口，你可以允许用户选择单个或者多个行：

ListSelectionModel有下面这些字段：

    * SINGLE_SELECTION允许一次选择一行。
    * SINGLE_INTERVAL_SELECTION允许选择相邻的一系列行。
    * MULTIPLE_INTERVAL_SELECTION也允许选择相邻的列，但是带有扩展功能。它允许用户使用[Ctrl]键进行多个互不相邻的选择（即选择不相邻的行）。

setCellSelectionEnabled()方法让用户能够同时选择单个单元格或者整个行：

编辑单元格

我们这个简单的表格允许用户编辑表格里的任何单元格。Listing B列出了一个表格，它允许由程序员来决定哪些单元格能够被编辑。第一步是创建一个自定义的TableModel：

简单的表格验证

你需要确保用户只输入整数值，假如说，向第二列（“盒子的数量”这一列）输入值来强制替代setValueAt()方法，并将验证逻辑包括进这个新方法里。首先，你要检查列是否是整数，以及这个列是否只应该包含整数值：

背景颜色

Listing C包含了用于ColorTable.java的代码，它说明了如何向JTable加入颜色。你可以通过强制替代其prepareRenderer()方法来向JTable加入背景颜色：

一切皆在掌握中

我们的例子只是JTable其他部分的基础。通过使用这些工具，你能够快速和轻易地掌控对Java应用程序所生成的表格的格式化，这样就能够让你的用户在进行正常使用的时候不碰到障碍。

摘自：http://www.7dspace.com/doc/21/0601/20061905111047137.htm

一个单元(Unit)是指一个可独立进行的工作，独立进行指的是这个工作不受前一次或接下来的工作的结果影响。简单地说，就是不与程序运行时的上下文(Context)发生关系。

如果是在Java程序中，具体来说一个单元可以是指一个方法(Method)。这个方法不依赖于前一次运行的结果，也不牵涉到后一次的运行结果。

举例来说，下面这个程序的gcd()方法可视为一个单元：

package onlyfun.caterpillar;

public class MathTool {

    public static int gcd(int num1, int num2) {

        int r = 0;

        while(num2 != 0) {

            r = num1 % num2;

            num1 = num2;

            num2 = r;

        }

        return num1;

    }

下面的gcd()方法不可视为一个单元，要完成gcd的计算，必须调用setNum1()、setNum2()与gcd() 3个方法。

package onlyfun.caterpillar;

public class MathFoo {

    private static int num1;

    private static int num2;

    public static void setNum1(int n) {

        num1 = n;

    }

    public static void setNum2(int n) {

        num2 = n;

    }

    public static int gcd() {

        int r = 0;

        while(num2 != 0) {

            r = num1 % num2;

            num1 = num2;

            num2 = r;

        }

        return num1;

    }

然而要完全使用一个方法来完成一个单元操作在实现上是有困难的，所以单元也可广义解释为数个方法的集合。这数个方法组合为一个单元操作，目的是完成一个任务。

不过设计时仍优先考虑将一个公开的方法设计为单元，辅助的方法则使用设定为私用，尽量不用数个公开的方法来完成一件工作，以保持接口简洁与单元边界清晰。将工作以一个单元进行设计，这使得单元可以重用，并且也使得单元可以进行测试，进而增加类的可重用性。

单元测试指的是对每一个工作单元进行测试，了解其运行结果是否符合我们的要求。例如当编写完MathTool类之后，也许会这么写一个小小的测试程序：

package test.onlyfun.caterpillar;

import onlyfun.caterpillar.MathTool;

public class MathToolTest {

    public static void main(String[] args) {

        if(MathTool.gcd(10, 5) == 5) {

            System.out.println("GCD Test OK!");

        }

        else {

            System.out.println("GCD Test Fail!");

        }

    }

在文字模式下使用文字信息显示测试结果，这个动作是开发人员经常作的事情，然而您必须一行一行看着测试程序的输出结果，以了解测试是否成功。另一方面，测试程序本身也是一个程序，在更复杂的测试中，也许会遇到测试程序本身出错，而导致无法验证结果的情况。

JUnit是一个测试框架，通过它所提供的工具，可以减少编写错误的测试程序的机会。另一方面，可以有更好的方法来检验测试结果，而不是看着一长串输出的文字来检验测试是否成功。JUnit测试框架让测试的进行更有效率且更具可靠性。

B.2　JUnit设置

JUnit最初是由Erich Gamma与Kent Beck编写，为单元测试的支持框架，用来编写与执行重复性的测试。它包括以下特性：

Ü   对预期结果作判断

Ü   提供测试装备的生成与销毁

Ü   易于组织与执行测试

Ü   图形与文字接口的测试器

要设定JUnit，可先到 JUnit官方网站(http://junit.org/)下载JUnit的zip文件，下载后解开压缩文件，其中会含有junit.jar文件，将这个文件复制到所要的数据夹中，然后设定Classpath指向junit.jar。例如：

set classpath=%classpath%;YOUR_JUNIT_DIR\junit.jar

如果是Windows 2000/XP，可以在环境变量中设定Classpath变量(可参考附录A中的Classpath设置介绍)。

B.3　第一个JUnit测试

要对程序进行测试，首先要设计测试案例(Test Case)。一个测试案例是对程序给予假定条件，然后运行程序并看看在给定的条件下，程序的运行结果是否符合要求。

在JUnit下，可以继承TestCase来编写测试案例，并定义测试方法，每一个测试方法是以testXXX()来命名。一个例子如下所示：

package test.onlyfun.caterpillar;

import onlyfun.caterpillar.MathTool;

import junit.framework.TestCase;

public class MathToolUnitTest extends TestCase {

    public void testGcd() {

        assertEquals(5, MathTool.gcd(10, 5));

    }

    public static void main(String[] args) {

        junit.textui.TestRunner.run(MathToolUnitTest.class);

    }

assertEquals()方法用来断定您的预期值与单元方法实际的返回结果是否相同，如果预期值与返回的结果不同则丢出异常，TestRunner会捕捉异常，并提取其中的相关信息以报告测试结果。这里使用的是文字模式的TestRunner。

接下来根据测试案例编写实际的程序，首先试着让测试案例能通过编译：

package onlyfun.caterpillar;

public class MathTool {

    public static int gcd(int num1, int num2) { 

        return 0;

    }

}

编译完MathTool.java并用javac来编译它。在编译完成之后，接着运行测试案例，会得到以下的结果：

.F

Time: 0

There was 1 failure:

1) testGcd(test.onlyfun.caterpillar.MathToolUnitTest)junit.framework.AssertionFa

iledError: expected:<5> but was:<0>

...略

FAILURES!!!

Tests run: 1,  Failures: 1,  Errors: 0

由于MathTool中并没有编写什么实际的逻辑，所以测试失败。在测试驱动中，测试案例所报告的结果通常是以测试失败作为开始，您的挑战就是要一步步消除这些失败的信息。接下来根据测试案例，完成所设计的程序：

package onlyfun.caterpillar;

public class MathTool {

    public static int gcd(int num1, int num2) {

        int r = 0;

        while(num2 != 0) {

            r = num1 % num2;

            num1 = num2;

            num2 = r;

        }

        return num1;

    }

再次运行测试案例，会得到以下的结果，通过最后的OK信息，知道测试已经成功：

.Time: 0

OK (1 test)

不一定要在main()中指定TestRunner，而可以直接启动一个TestRunner，并指定测试案例类(继承TestCase的类)。例如启动一个Swing窗口的测试结果画面：

java junit.swingui.TestRunner test.onlyfun.caterpillar.MathToolUnitTest

执行的结果画面如图B-1所示。

在Swing窗口的测试结果显示中，如果中间的横棒是显示绿色，表示所有的测试都已经成功，如果中间的横棒显示红色，表示测试失败。JUnit的名言是Keep the bar green to keep the code clean，意思是保持绿色横棒以保证测试成功。

也可以指定文字模式的测试结果。例如：

java junit.textui.TestRunner test.onlyfun.caterpillar.MathToolUnitTest

图B-1  JUnit的Swing窗口测试结果

B.4　自动构建与测试

Ant可以进行自动化构建，而JUnit可以进行自动化测试，Ant可以与JUnit结合，使得自动化的构建与测试变得可行。

如果要让Ant能支持JUnit，建议直接将JUnit的junit.jar放置在Ant的lib目录，并记得改变Classpath中原先有关junit.jar的设定。例如将Classpath重新指向%ANT_HOME%\lib\junit.jar(假设已经如附录A中设置了ant_home的环境变量)。虽然也有其他的方式可以设定，但这是最快也是最简单的方法。

Ant使用<junit>标签来设定JUnit测试，下面是一个简单的例子：

<?xml version="1.0"?>

<project name="autoBuildTest" default="test">

    <target name="setProperties">

        <property name="src.dir" value="src"/>

        <property name="classes.dir" value="classes"/>

    </target>

    <target name="prepareDir" depends="setProperties">

        <delete dir="${classes.dir}"/>

        <mkdir dir="${classes.dir}"/>

    </target>

    <target name="compile" depends="prepareDir">

        <javac srcdir="${src.dir}" destdir="${classes.dir}"/>

    </target>

    <target name="test" depends="compile">

        <junit printsummary="yes">

            <test

               name="test.onlyfun.caterpillar.MathToolUnitTest"/>

            <classpath>

                <pathelement location="${classes.dir}"/>

            </classpath>

        </junit>

    </target>

printsummary属性会将测试的结果简单地显示出来，<test>的name属性是设定所要进行测试的测试案例类。Ant构建与调用JUnit进行测试的信息如下：

C:\workspace\B>ant

Buildfile: build.xml

setProperties:

prepareDir:

    [mkdir] Created dir: C:\workspace\B\classes

compile:

    [javac] Compiling 4 source files to C:\workspace\B\classes

test:

    [junit] Running test.onlyfun.caterpillar.MathToolUnitTest

    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0 sec

BUILD SUCCESSFUL

Total time: 1 second

B.5　自动生成测试报告

接上一个主题，可以将JUnit的测试过程在Ant构建过程中显示出来，只要加入< formatter>标签设定即可：

<?xml version="1.0"?>

<project name="autoBuildTest" default="test">

    ...

    <target name="test" depends="compile"> 

        <junit printsummary="yes"> 

            <formatter type="plain" usefile="false"/>

            <test 

               name="test.onlyfun.caterpillar.MathToolUnitTest"/> 

            <classpath> 

                <pathelement location="${classes.dir}"/> 

            </classpath> 

        </junit> 

    </target>

</project>

Ant构建与调用JUnit进行测试的信息如下：

C:\workspace\B>ant

Buildfile: build.xml

setProperties:

prepareDir:

   [delete] Deleting directory C:\workspace\B\classes

    [mkdir] Created dir: C:\workspace\B\classes

compile:

    [javac] Compiling 4 source files to C:\workspace\B\classes

test:

    [junit] Running test.onlyfun.caterpillar.MathToolUnitTest

    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.016 sec

    [junit] Testsuite: test.onlyfun.caterpillar.MathToolUnitTest

    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.016 sec

    [junit] Testcase: testGcd took 0.016 sec

BUILD SUCCESSFUL

Total time: 2 seconds

当usefile属性设定为true时，会自动将产生的结果保存在文件中，默认是TEST-*.txt。其中*是测试案例类名称。就上例而言，所产生的报告文件内容如下：

Testsuite: test.onlyfun.caterpillar.MathToolUnitTest

Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0 sec

Testcase: testGcd took 0 sec

<formatter>标签还可以设定将测试的结果，以XML文件保存下来。一个编写的例子如下，它将测试的结果保存至report目录中， 文件名称为TEST-*.xml，*是测试案例类名称：

<?xml version="1.0"?>

    ...

    <target name="test" depends="compile"> 

        <junit printsummary="yes"> 

            <formatter type="xml"/>

            <test 

               name="test.onlyfun.caterpillar.MathToolUnitTest"/> 

            <classpath> 

                <pathelement location="${classes.dir}"/> 

            </classpath> 

        </junit> 

    </target>

</project>

也可以将测试结果所产生的XML文件转换为HTML文件，使用Ant可以直接完成这个工作。<junitreport>标签使用 XSLT将XML文件转换为HTML文件。下面的例子将前面的说明作个总结，以完整呈现编写的实例：

<?xml version="1.0"?>

<project name="autoBuildTest" default="report">

    <target name="setProperties">

        <property name="src.dir" value="src"/>

        <property name="classes.dir" value="classes"/>

        <property name="report.dir" value="report"/>       

    </target>

    <target name="prepareDir" depends="setProperties">

        <delete dir="${report.dir}"/>

        <delete dir="${classes.dir}"/>

        <mkdir dir="${report.dir}"/>

        <mkdir dir="${classes.dir}"/>

    </target>

    <target name="compile" depends="prepareDir">

        <javac srcdir="${src.dir}" destdir="${classes.dir}"/>

    </target> 

    <target name="test" depends="compile">

        <junit printsummary="yes">

            <formatter type="xml"/>

            <test

               name="test.onlyfun.caterpillar.MathToolUnitTest"/>

            <classpath>

                <pathelement location="${classes.dir}"/>

            </classpath>

        </junit>

    </target>

    <target name="report" depends="test">

        <junitreport todir="${report.dir}">

            <fileset dir="${report.dir}">

                <include name="TEST-*.xml"/>

            </fileset>

            <report

                format="frames" todir="${report.dir}/html"/>

        </junitreport>

    </target>   

<include>设定搜寻TEST-*.xml文件，将之转换为HTML文件，而最后的结果被设定保存至report/html/目录下，在format属性中设定了HTML文件具有边框(Frame)，如果不设定这个属性，则HTML报告文件就不具有边框。在运行Ant之后所产生的 HTML测试结果报告文件如图B-2所示。

图B-2  Ant结合JUnit所自动产生的测试报告

附录B只是对JUnit的一些简介，如果需要更多有关JUnit的资料，可以参考以下的网址：

http://caterpillar.onlyfun.net/Gossip/JUnit/JUnitGossip.htm

    包括：
    “>> 右移”；“<< 左移”；“>>> 无符号右移”

例子：
-5>>3=-1
1111 1111 1111 1111 1111 1111 1111 1011
1111 1111 1111 1111 1111 1111 1111 1111
其结果与 Math.floor((double)-5/(2*2*2)) 完全相同。

-5<<3=-40
1111 1111 1111 1111 1111 1111 1111 1011
1111 1111 1111 1111 1111 1111 1101 1000
其结果与 -5*2*2*2 完全相同。

5>>3=0
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0000
其结果与 5/(2*2*2) 完全相同。

5<<3=40
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0010 1000
其结果与 5*2*2*2 完全相同。

-5>>>3=536870911     
1111 1111 1111 1111 1111 1111 1111 1011
0001 1111 1111 1111 1111 1111 1111 1111

无论正数、负数，它们的右移、左移、无符号右移 32 位都是其本身，比如 -5<<32=-5、-5>>32=-5、-5>>>32=-5。
一个有趣的现象是，把 1 左移 31 位再右移 31 位，其结果为 -1。
0000 0000 0000 0000 0000 0000 0000 0001
1000 0000 0000 0000 0000 0000 0000 0000
1111 1111 1111 1111 1111 1111 1111 1111

位逻辑运算符

    包括：
    & 与；| 或；~ 非（也叫做求反）；^ 异或

    “& 与”、“| 或”、“~ 非”是基本逻辑运算，由此可以演变出“与非”、“或非”、“与或非”复合逻辑运算。“^ 异或”是一种特殊的逻辑运算，对它求反可以得到“同或”，所以“同或”逻辑也叫“异或非”逻辑。

例子：
5&3=1
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0001

-5&3=1
1111 1111 1111 1111 1111 1111 1111 1011
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0011

5|3=7
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0111

-5|3=-5
1111 1111 1111 1111 1111 1111 1111 1011
0000 0000 0000 0000 0000 0000 0000 0011
1111 1111 1111 1111 1111 1111 1111 1011

~5=-6
0000 0000 0000 0000 0000 0000 0000 0101
1111 1111 1111 1111 1111 1111 1111 1010

~-5=4
1111 1111 1111 1111 1111 1111 1111 1011
0000 0000 0000 0000 0000 0000 0000 0100

5^3=6
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0110

-5^3=-8
1111 1111 1111 1111 1111 1111 1111 1011
0000 0000 0000 0000 0000 0000 0000 0011
1111 1111 1111 1111 1111 1111 1111 1000



请注意！引用、转贴本文应注明原作者：Rosen Jiang 以及出处：http://www.blogjava.net/rosen

try{
    javax.swing.UIManager.setLookAndFeel(new com.sun.java.swing.plaf.windows.WindowsLookAndFeel());
    javax.swing.SwingUtilities.updateComponentTreeUI(this);
}catch(javax.swing.UnsupportedLookAndFeelException e){
    e.printStackTrace();
}

后者在运行时对整个ComponentTree进行更新，应用当前的UI设置。

public static void setLookAndFeel(String className, java.awt.Component c) {
    try {
      UIManager.setLookAndFeel(className);
      SwingUtilities.updateComponentTreeUI(c);//注意这行
    }
    catch (Exception ex) {
      ex.printStackTrace();
      JOptionPane.showMessageDialog(null,
                                    "不好意思,setLookAndFeel时出错了:( Errormsg:" + ex,
                                    "setLookAndFeel",
                                    JOptionPane.INFORMATION_MESSAGE);
    }

对于简单的程序使用Boborderlayout和Gridlayout就绰绰有余了, 但如果要把程序提到实际应用上你就得考虑使用GridBagLayout。当然, 做复杂的应用程序时，一开始就使用GridBagLayout就会更有效率。

一旦你决定使用GridBagLayout，接下来一步便是要找一些纸和铅笔,只有你准确知道你的界面看上去需要成什么样子，你就可以敲键盘。这就是说,你应该在编码之前进行妥善规划。

    下面将介绍一个很小的应用程序来帮助我们学习GridBagLayout，这个例子是从一个Flickr RSS fead中显示一系列照片, 最后的界面就像下面这样：

下面的是这个界面的一个原始草图：

正如你所看到的，最终的结果看上去和计划的想法完全一样。

    你应该能看到在草图里有一些线，这些线是用来把总界面分成若干行和列的，这样你就很清楚每一个组件放置的格子位置。这就是GridBagLayout里"格"的那一部分，而图上的数字就是格的号码。

在某种意义上说, 我们可以把GridBagLayout想象成为早些年的HTML3和4，它们都是基于表的布局，Grid的概念就类似rowspan和colspan的意思，只不过换了个名字罢了。

随着我们的界面和表格的设置完成，是时候该进行界面布局并开始写代码了。

工作过程

这一节我假定你已经了解了基本的窗口和组件创建知识。

通过这篇文章我们最终能在一个frame中布局组件，我们将在以后的文章对界面进行改进使它更适用。因此,为了了解这整个工作的过程，我们列出了所有的目标代码。

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class GridBagWindow extends JFrame {
private JButton searchBtn;
private JComboBox modeCombo;
private JLabel tagLbl;
private JLabel tagModeLbl;
private JLabel previewLbl;
private JTable resTable;
private JTextField tagTxt;
public GridBagWindow() {
Container contentPane = getContentPane();
GridBagLayout gridbag = new GridBagLayout();
contentPane.setLayout(gridbag);
GridBagConstraints c = new GridBagConstraints();
//setting a default constraint value
c.fill =GridBagConstraints.HORIZONTAL;
tagLbl = new JLabel("Tags");
c.gridx = 0; //x grid position
c.gridy = 0; //y grid position
gridbag.setConstraints(tagLbl, c); //associate the label with a constraint object
contentPane.add(tagLbl); //add it to content pane
tagModeLbl = new JLabel("Tag Mode");
c.gridx = 0;
c.gridy = 1;
gridbag.setConstraints(tagModeLbl, c);
contentPane.add(tagModeLbl);
tagTxt = new JTextField("plinth");
c.gridx = 1;
c.gridy = 0;
c.gridwidth = 2;
gridbag.setConstraints(tagTxt, c);
contentPane.add(tagTxt);
String[] options = {"all", "any"};
modeCombo = new JComboBox(options);
c.gridx = 1;
c.gridy = 1;
c.gridwidth = 1;
gridbag.setConstraints(modeCombo, c);
contentPane.add(modeCombo);
searchBtn = new JButton("Search");
c.gridx = 1;
c.gridy = 2;
gridbag.setConstraints(searchBtn, c);
contentPane.add(searchBtn);
resTable = new JTable(5,3);
c.gridx = 0;
c.gridy = 3;
c.gridwidth = 3;
gridbag.setConstraints(resTable, c);
contentPane.add(resTable);
previewLbl = new JLabel("Preview goes here");
c.gridx = 0;
c.gridy = 4;
gridbag.setConstraints(previewLbl, c);
contentPane.add(previewLbl);
addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
});
}
public static void main(String args[]) {
GridBagWindow window = new GridBagWindow();
window.setTitle("GridBagWindow");
window.pack();
window.setVisible(true);
}
}

Container contentPane = getContentPane();

GridBagLayout gridbag = new GridBagLayout();

contentPane.setLayout(gridbag);

    我们以GridBagWindow的内容面板作为开始来创建一个GridBagLayout对象，准确地说，这个方法与过去我们所创建GridLayout对象和BorderLayout对象的方法是一样的。那么，现在我们就开始来设置GridBagLayout对象使它作为内容面板的布局。

GridBagConstraints c = new GridBagConstraints();

    然后我要提到这整个进程中的一个独特的对象，那就是GridBagConstraints。这个对象在GridBagLayout中控制所有被安置在其中组件的约束。为了把一个组件增加到你的GridBagLayout中去，你首先必须将它与一个GridBagConstraints对象建立连接。

GridBagConstraints可以从11个方面来进行控制和操纵，也可以给你提供一些帮助。这些内容是：

• Gridx——组件的横向坐标
• Girdy——组件的纵向坐标
• Gridwidth——组件的横向宽度，也就是指组件占用的列数，这与HTML的colspan类似
• Gridheight——组件的纵向长度，也就是指组件占用的行数，这与HTML的rowspan类似
• Weightx——指行的权重，告诉布局管理器如何分配额外的水平空间
• Weighty——指列的权重，告诉布局管理器如何分配额外的垂直空间
• Anchor——告诉布局管理器组件在表格空间中的位置
• Fill——如果显示区域比组件的区域大的时候，可以用来控制组件的行为。控制组件是垂直填充，还是水平填充，或者两个方向一起填充
• Insets——指组件与表格空间四周边缘的空白区域的大小
• Ipadx—— 组件间的横向间距,组件的宽度就是这个组件的最小宽度加上ipadx值
• ipady—— 组件间的纵向间距,组件的高度就是这个组件的最小高度加上ipady值

    可能对于一个组件的每一个实例你都需要为它建立一个单独的GridBagConstraints；然而，这种方法我们并不推荐使用。最好的方法是，当你调用它的时候把对象设置为默认值，然后针对于每一个组件改变其相应的域。

    这个方法具有通用性，因为在一些域中，比如insets、padx、pady和fill这些域，对于每一个组件来说一般都是相同的，因此这样对一个域进行设置就会更轻松了，也能更轻松的在另外的组件中改变某些域的值。

    如果在改变了某些域值之后，你想回到原始的域值的话，你应该在增加下一个组件之前进行改变。这种方法使你更容易明白你正在修改的内容，也能使你更容易明白在一连串对象中的这11个参数的作用。

    也许你现在对这些内容还是一知半解，不过事实上一旦你理解了GridBagConstraints，值得安慰的是你以后做再困难的工作都会游刃有余了。

所以，如果我们已经明白了GridBagConstraints的详细用法了，那么现在就让我们来看看在实际应用中应该如何来实现它：

tagLbl = new JLabel("Tags");
c.gridx = 0; //x grid position
c.gridy = 0; //y grid position
gridbag.setConstraints(tagLbl, c); //设置标签的限制

contentPane.add(tagLbl); //增加到内容面板

我们所做的是示例我们的标签、分配给它一个格位置，将它与一个约束对象联系起来并把它增加到我们的内容面板中。

tagModeLbl = new JLabel("Tag Mode");
c.gridx = 0;
c.gridy = 1;
gridbag.setConstraints(tagModeLbl, c);

contentPane.add(tagModeLbl);

  请注意，虽然我们已经在我们的约束对象中把gridx的值设置为0，但是在这里我们仍然要对它进行重新设置——这样做没有其它原因，只是为了增加可读性。

    下面，我们增加一个文本域以便能存储我们希望能搜索到的关键字，再增加一个组合框以便用来搜索多个关键字。除了我们希望的文本域有两列之外，这个概念其他的方面都与上面所说的是相同的，所以，我们需要在增加组合框之前重新设置文本域的值。

tagTxt = new JTextField("plinth");
c.gridx = 1;
c.gridy = 0;
c.gridwidth = 2;
gridbag.setConstraints(tagTxt, c);
contentPane.add(tagTxt);

String[] options = {"all", "any"};
modeCombo = new JComboBox(options);
c.gridx = 1;
c.gridy = 1;
c.gridwidth = 1;
gridbag.setConstraints(modeCombo, c);
contentPane.add(modeCombo);

      做了这些之后，我们再在内容面板中增加一些其余的简单组件，这时候我们就能够浏览它了；其余的代码应该不会出现任何问题了。

到这个阶段，我们应该已经得到了一个类似于我们先前所设计的界面了。

进一步学习

     当然，界面不是智能的。重新设置窗口的大小，看看将会发生些什么事情。为什么它会那样呢？那是因为我们设置了约束对象的weightx、weighty和fill的值。

关于其他类似的一些内容我们将在后面的章节中进行介绍，但是如果你希望能自己试试的话，参考GridBigLayout和GridBagConstraintsAPI文档会对扩充你的知识提供很好的帮助。

Documentation for release 2.3 (July 9 2007)
© 2001-2007 OFFIS, Tammo Freese.

EasyMock 2 is a library that provides an easy way to use Mock Objects for given interfaces. EasyMock 2 is available under the terms of the MIT license.

Mock Objects simulate parts of the behavior of domain code, and are able to check whether they are used as defined. Domain classes can be tested in isolation by simulating their collaborators with Mock Objects.

Writing and maintaining Mock Objects often is a tedious task that may introduce errors. EasyMock 2 generates Mock Objects dynamically - no need to write them, and no generated code!

EasyMock 2 Benefits

• Hand-writing classes for Mock Objects is not needed.
• Supports refactoring-safe Mock Objects: test code will not break at runtime when renaming methods or reordering method parameters
• Supports return values and exceptions.
• Supports checking the order of method calls, for one or more Mock Objects.

EasyMock 2 Drawbacks

• EasyMock 2 does only work with Java 2 Version 5.0 and above.

EasyMock by default supports the generation of Mock Objects for interfaces only. For those who would like to generate Mock Objects for classes, there is an extension available at the EasyMock home page.

Installation

1. Java 2 (at least 5.0) is required.
2. Unzip the EasyMock zip file (easymock2.3.zip). It contains a directory easymock2.3. Add the EasyMock jar file (easymock.jar) from this directory to your classpath.

To execute the EasyMock tests, add tests.zip and the JUnit 4.1 jar to your class path and start 'java org.easymock.tests.AllTests'.

The source code of EasyMock is stored in the zip file src.zip.

Usage

Most parts of a software system do not work in isolation, but collaborate with other parts to get their job done. In a lot of cases, we do not care about using collaborators in unit testing, as we trust these collaborators. If we do care about it, Mock Objects help us to test the unit under test in isolation. Mock Objects replace collaborators of the unit under test.

The following examples use the interface Collaborator:

package org.easymock.samples;
public interface Collaborator {
void documentAdded(String title);
void documentChanged(String title);
void documentRemoved(String title);
byte voteForRemoval(String title);
byte[] voteForRemovals(String[] title);
}

Implementors of this interface are collaborators (in this case listeners) of a class named ClassUnderTest:

public class ClassUnderTest {
// ...
public void addListener(Collaborator listener) {
// ...
}
public void addDocument(String title, byte[] document) {
// ...
}
public boolean removeDocument(String title) {
// ...
}
public boolean removeDocuments(String[] titles) {
// ...
}
}

The code for both the class and the interface may be found in the package org.easymock.samples in samples.zip.

The following examples assume that you are familiar with the JUnit testing framework. Although the tests shown here use JUnit in version 3.8.1, you may as well use JUnit 4 or TestNG.

The first Mock Object

We will now build a test case and toy around with it to understand the functionality of the EasyMock package. samples.zip contains a modified version of this test. Our first test should check whether the removal of a non-existing document does not lead to a notification of the collaborator. Here is the test without the definition of the Mock Object:

package org.easymock.samples;
import junit.framework.TestCase;
public class ExampleTest extends TestCase {
private ClassUnderTest classUnderTest;
private Collaborator mock;
protected void setUp() {
classUnderTest = new ClassUnderTest();
classUnderTest.addListener(mock);
}
public void testRemoveNonExistingDocument() {
// This call should not lead to any notification
// of the Mock Object:
classUnderTest.removeDocument("Does not exist");
}
}

For many tests using EasyMock 2, we only need a static import of methods of org.easymock.EasyMock. This is the only non-internal, non-deprecated class of EasyMock 2.

import static org.easymock.EasyMock.*;
import junit.framework.TestCase;
public class ExampleTest extends TestCase {
private ClassUnderTest classUnderTest;
private Collaborator mock;
}

To get a Mock Object, we need to

1. create a Mock Object for the interface we would like to simulate,
2. record the expected behavior, and
3. switch the Mock Object to replay state.

Here is a first example:

    protected void setUp() {
mock = createMock(Collaborator.class); // 1
classUnderTest = new ClassUnderTest();
classUnderTest.addListener(mock);
}
public void testRemoveNonExistingDocument() {
// 2 (we do not expect anything)
replay(mock); // 3
classUnderTest.removeDocument("Does not exist");
}

After activation in step 3, mock is a Mock Object for the Collaborator interface that expects no calls. This means that if we change our ClassUnderTest to call any of the interface's methods, the Mock Object will throw an AssertionError:

java.lang.AssertionError:
Unexpected method call documentRemoved("Does not exist"):
at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:29)
at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44)
at $Proxy0.documentRemoved(Unknown Source)
at org.easymock.samples.ClassUnderTest.notifyListenersDocumentRemoved(ClassUnderTest.java:74)
at org.easymock.samples.ClassUnderTest.removeDocument(ClassUnderTest.java:33)
at org.easymock.samples.ExampleTest.testRemoveNonExistingDocument(ExampleTest.java:24)
...

Adding Behavior

Let us write a second test. If a document is added on the class under test, we expect a call to mock.documentAdded() on the Mock Object with the title of the document as argument:

    public void testAddDocument() {
mock.documentAdded("New Document"); // 2
replay(mock); // 3
classUnderTest.addDocument("New Document", new byte[0]);
}

So in the record state (before calling replay), the Mock Object does not behave like a Mock Object, but it records method calls. After calling replay, it behaves like a Mock Object, checking whether the expected method calls are really done.

If classUnderTest.addDocument("New Document", new byte[0]) calls the expected method with a wrong argument, the Mock Object will complain with an AssertionError:

java.lang.AssertionError:
Unexpected method call documentAdded("Wrong title"):
documentAdded("New Document"): expected: 1, actual: 0
at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:29)
at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44)
at $Proxy0.documentAdded(Unknown Source)
at org.easymock.samples.ClassUnderTest.notifyListenersDocumentAdded(ClassUnderTest.java:61)
at org.easymock.samples.ClassUnderTest.addDocument(ClassUnderTest.java:28)
at org.easymock.samples.ExampleTest.testAddDocument(ExampleTest.java:30)
...

All missed expectations are shown, as well as all fulfilled expectations for the unexpected call (none in this case). If the method call is executed too often, the Mock Object complains, too:

java.lang.AssertionError:
Unexpected method call documentAdded("New Document"):
documentAdded("New Document"): expected: 1, actual: 1 (+1)
at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:29)
at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44)
at $Proxy0.documentAdded(Unknown Source)
at org.easymock.samples.ClassUnderTest.notifyListenersDocumentAdded(ClassUnderTest.java:62)
at org.easymock.samples.ClassUnderTest.addDocument(ClassUnderTest.java:29)
at org.easymock.samples.ExampleTest.testAddDocument(ExampleTest.java:30)
...

Verifying Behavior

There is one error that we have not handled so far: If we specify behavior, we would like to verify that it is actually used. The current test would pass if no method on the Mock Object is called. To verify that the specified behavior has been used, we have to call verify(mock):

    public void testAddDocument() {
mock.documentAdded("New Document"); // 2
replay(mock); // 3
classUnderTest.addDocument("New Document", new byte[0]);
verify(mock);
}

If the method is not called on the Mock Object, we now get the following exception:

java.lang.AssertionError:
Expectation failure on verify:
documentAdded("New Document"): expected: 1, actual: 0
at org.easymock.internal.MocksControl.verify(MocksControl.java:70)
at org.easymock.EasyMock.verify(EasyMock.java:536)
at org.easymock.samples.ExampleTest.testAddDocument(ExampleTest.java:31)
...

The message of the exception lists all missed expectations.

Expecting an Explicit Number of Calls

Up to now, our test has only considered a single method call. The next test should check whether the addition of an already existing document leads to a call to mock.documentChanged() with the appropriate argument. To be sure, we check this three times (hey, it is an example ;-)):

    public void testAddAndChangeDocument() {
mock.documentAdded("Document");
mock.documentChanged("Document");
mock.documentChanged("Document");
mock.documentChanged("Document");
replay(mock);
classUnderTest.addDocument("Document", new byte[0]);
classUnderTest.addDocument("Document", new byte[0]);
classUnderTest.addDocument("Document", new byte[0]);
classUnderTest.addDocument("Document", new byte[0]);
verify(mock);
}

To avoid the repetition of mock.documentChanged("Document"), EasyMock provides a shortcut. We may specify the call count with the method times(int times) on the object returned by expectLastCall(). The code then looks like:

    public void testAddAndChangeDocument() {
mock.documentAdded("Document");
mock.documentChanged("Document");
expectLastCall().times(3);
replay(mock);
classUnderTest.addDocument("Document", new byte[0]);
classUnderTest.addDocument("Document", new byte[0]);
classUnderTest.addDocument("Document", new byte[0]);
classUnderTest.addDocument("Document", new byte[0]);
verify(mock);
}

If the method is called too often, we get an exception that tells us that the method has been called too many times. The failure occurs immediately at the first method call exceeding the limit:

java.lang.AssertionError:
Unexpected method call documentChanged("Document"):
documentChanged("Document"): expected: 3, actual: 3 (+1)
at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:29)
at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44)
at $Proxy0.documentChanged(Unknown Source)
at org.easymock.samples.ClassUnderTest.notifyListenersDocumentChanged(ClassUnderTest.java:67)
at org.easymock.samples.ClassUnderTest.addDocument(ClassUnderTest.java:26)
at org.easymock.samples.ExampleTest.testAddAndChangeDocument(ExampleTest.java:43)
...

If there are too few calls, verify(mock) throws an AssertionError:

java.lang.AssertionError:
Expectation failure on verify:
documentChanged("Document"): expected: 3, actual: 2
at org.easymock.internal.MocksControl.verify(MocksControl.java:70)
at org.easymock.EasyMock.verify(EasyMock.java:536)
at org.easymock.samples.ExampleTest.testAddAndChangeDocument(ExampleTest.java:43)
...

Specifying Return Values

For specifying return values, we wrap the expected call in expect(T value) and specify the return value with the method andReturn(Object returnValue) on the object returned by expect(T value).

As an example, we check the workflow for document removal. If ClassUnderTest gets a call for document removal, it asks all collaborators for their vote for removal with calls to byte voteForRemoval(String title) value. Positive return values are a vote for removal. If the sum of all values is positive, the document is removed and documentRemoved(String title) is called on all collaborators:

    public void testVoteForRemoval() {
mock.documentAdded("Document");   // expect document addition
// expect to be asked to vote for document removal, and vote for it
expect(mock.voteForRemoval("Document")).andReturn((byte) 42);
mock.documentRemoved("Document"); // expect document removal
replay(mock);
classUnderTest.addDocument("Document", new byte[0]);
assertTrue(classUnderTest.removeDocument("Document"));
verify(mock);
}
public void testVoteAgainstRemoval() {
mock.documentAdded("Document");   // expect document addition
// expect to be asked to vote for document removal, and vote against it
expect(mock.voteForRemoval("Document")).andReturn((byte) -42);
replay(mock);
classUnderTest.addDocument("Document", new byte[0]);
assertFalse(classUnderTest.removeDocument("Document"));
verify(mock);
}

The type of the returned value is checked at compile time. As an example, the following code will not compile, as the type of the provided return value does not match the method's return value:

    expect(mock.voteForRemoval("Document")).andReturn("wrong type");

Instead of calling expect(T value) to retrieve the object for setting the return value, we may also use the object returned by expectLastCall(). Instead of

    expect(mock.voteForRemoval("Document")).andReturn((byte) 42);

we may use

    mock.voteForRemoval("Document");
expectLastCall().andReturn((byte) 42);

This type of specification should only be used if the line gets too long, as it does not support type checking at compile time.

Working with Exceptions

For specifying exceptions (more exactly: Throwables) to be thrown, the object returned by expectLastCall() and expect(T value) provides the method andThrow(Throwable throwable). The method has to be called in record state after the call to the Mock Object for which it specifies the Throwable to be thrown.

Unchecked exceptions (that is, RuntimeException, Error and all their subclasses) can be thrown from every method. Checked exceptions can only be thrown from the methods that do actually throw them.

Creating Return Values or Exceptions

Sometimes we would like our mock object to return a value or throw an exception that is created at the time of the actual call. Since EasyMock 2.2, the object returned by expectLastCall() and expect(T value) provides the method andAnswer(IAnswer answer) which allows to specify an implementation of the interface IAnswer that is used to create the return value or exception.

Inside an IAnswer callback, the arguments passed to the mock call are available via EasyMock.getCurrentArguments(). If you use these, refactorings like reordering parameters may break your tests. You have been warned.

Changing Behavior for the Same Method Call

It is also possible to specify a changing behavior for a method. The methods times, andReturn, and andThrow may be chained. As an example, we define voteForRemoval("Document") to

• return 42 for the first three calls,
• throw a RuntimeException for the next four calls,
• return -42 once.

    expect(mock.voteForRemoval("Document"))
.andReturn((byte) 42).times(3)
.andThrow(new RuntimeException(), 4)
.andReturn((byte) -42);

Relaxing Call Counts

To relax the expected call counts, there are additional methods that may be used instead of times(int count):

times(int min, int max)

to expect between min and max calls,

atLeastOnce()

to expect at least one call, and

anyTimes()

to expected an unrestricted number of calls.

If no call count is specified, one call is expected. If we would like to state this explicitely, once() or times(1) may be used.

Strict Mocks

On a Mock Object returned by a EasyMock.createMock(), the order of method calls is not checked. If you would like a strict Mock Object that checks the order of method calls, use EasyMock.createStrictMock() to create it.

If an unexpected method is called on a strict Mock Object, the message of the exception will show the method calls expected at this point followed by the first conflicting one. verify(mock) shows all missing method calls.

Switching Order Checking On and Off

Sometimes, it is necessary to have a Mock Object that checks the order of only some calls. In record phase, you may switch order checking on by calling checkOrder(mock, true) and switch it off by calling checkOrder(mock, false).

There are two differences between a strict Mock Object and a normal Mock Object:

1. A strict Mock Object has order checking enabled after creation.
2. A strict Mock Object has order checking enabled after reset (see Reusing a Mock Object).

Flexible Expectations with Argument Matchers

To match an actual method call on the Mock Object with an expectation, Object arguments are by default compared with equals(). This may lead to problems. As an example, we consider the following expectation:

String[] documents = new String[] { "Document 1", "Document 2" };
expect(mock.voteForRemovals(documents)).andReturn(42);

If the method is called with another array with the same contents, we get an exception, as equals() compares object identity for arrays:

java.lang.AssertionError:
Unexpected method call voteForRemovals([Ljava.lang.String;@9a029e):
voteForRemovals([Ljava.lang.String;@2db19d): expected: 1, actual: 0
documentRemoved("Document 1"): expected: 1, actual: 0
documentRemoved("Document 2"): expected: 1, actual: 0
at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:29)
at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44)
at $Proxy0.voteForRemovals(Unknown Source)
at org.easymock.samples.ClassUnderTest.listenersAllowRemovals(ClassUnderTest.java:88)
at org.easymock.samples.ClassUnderTest.removeDocuments(ClassUnderTest.java:48)
at org.easymock.samples.ExampleTest.testVoteForRemovals(ExampleTest.java:83)
...

To specify that only array equality is needed for this call, we may use the method aryEq that is statically imported from the EasyMock class:

String[] documents = new String[] { "Document 1", "Document 2" };
expect(mock.voteForRemovals(aryEq(documents))).andReturn(42);

If you would like to use matchers in a call, you have to specify matchers for all arguments of the method call.

There are a couple of predefined argument matchers available.

eq(X value)

Matches if the actual value is equals the expected value. Available for all primitive types and for objects.

anyBoolean(), anyByte(), anyChar(), anyDouble(), anyFloat(), anyInt(), anyLong(), anyObject(), anyShort()

Matches any value. Available for all primitive types and for objects.

eq(X value, X delta)

Matches if the actual value is equal to the given value allowing the given delta. Available for float and double.

aryEq(X value)

Matches if the actual value is equal to the given value according to Arrays.equals(). Available for primitive and object arrays.

isNull()

Matches if the actual value is null. Available for objects.

notNull()

Matches if the actual value is not null. Available for objects.

same(X value)

Matches if the actual value is the same as the given value. Available for objects.

isA(Class clazz)

Matches if the actual value is an instance of the given class, or if it is in instance of a class that extends or implements the given class. Available for objects.

lt(X value), leq(X value), geq(X value), gt(X value)

Matches if the actual value is less/less or equal/greater or equal/greater than the given value. Available for all numeric primitive types and Comparable.

startsWith(String prefix), contains(String substring), endsWith(String suffix)

Matches if the actual value starts with/contains/ends with the given value. Available for Strings.

matches(String regex), find(String regex)

Matches if the actual value/a substring of the actual value matches the given regular expression. Available for Strings.

and(X first, X second)

Matches if the matchers used in first and second both match. Available for all primitive types and for objects.

or(X first, X second)

Matches if one of the matchers used in first and second match. Available for all primitive types and for objects.

not(X value)

Matches if the matcher used in value does not match.

cmpEq(X value)

Matches if the actual value is equals according to Comparable.compareTo(X o). Available for all numeric primitive types and Comparable.

cmp(X value, Comparator comparator, LogicalOperator operator)

Matches if comparator.compare(actual, value) operator 0 where the operator is <,<=,>,>= or ==. Available for objects.

Defining your own Argument Matchers

Sometimes it is desirable to define own argument matchers. Let's say that an argument matcher is needed that matches an exception if the given exception has the same type and an equal message. It should be used this way:

    IllegalStateException e = new IllegalStateException("Operation not allowed.")
expect(mock.logThrowable(eqException(e))).andReturn(true);

Two steps are necessary to achieve this: The new argument matcher has to be defined, and the static method eqException has to be declared.

To define the new argument matcher, we implement the interface org.easymock.IArgumentMatcher. This interface contains two methods: matches(Object actual) checks whether the actual argument matches the given argument, and appendTo(StringBuffer buffer) appends a string representation of the argument matcher to the given string buffer. The implementation is straightforward:

import org.easymock.IArgumentMatcher;
public class ThrowableEquals implements IArgumentMatcher {
private Throwable expected;
public ThrowableEquals(Throwable expected) {
this.expected = expected;
}
public boolean matches(Object actual) {
if (!(actual instanceof Throwable)) {
return false;
}
String actualMessage = ((Throwable) actual).getMessage();
return expected.getClass().equals(actual.getClass())
&& expected.getMessage().equals(actualMessage);
}
public void appendTo(StringBuffer buffer) {
buffer.append("eqException(");
buffer.append(expected.getClass().getName());
buffer.append(" with message \"");
buffer.append(expected.getMessage());
buffer.append("\"")");
}
}

The method eqException must create the argument matcher with the given Throwable, report it to EasyMock via the static method reportMatcher(IArgumentMatcher matcher), and return a value so that it may be used inside the call (typically 0, null or false). A first attempt may look like:

public static Throwable eqException(Throwable in) {
EasyMock.reportMatcher(new ThrowableEquals(in));
return null;
}

However, this only works if the method logThrowable in the example usage accepts Throwables, and does not require something more specific like a RuntimeException. In the latter case, our code sample would not compile:

    IllegalStateException e = new IllegalStateException("Operation not allowed.")
expect(mock.logThrowable(eqException(e))).andReturn(true);

Java 5.0 to the rescue: Instead of defining eqException with a Throwable as parameter and return value, we use a generic type that extends Throwable:

public static <T extends Throwable> T eqException(T in) {
reportMatcher(new ThrowableEquals(in));
return null;
}

Reusing a Mock Object

Mock Objects may be reset by reset(mock).

Using Stub Behavior for Methods

Sometimes, we would like our Mock Object to respond to some method calls, but we do not want to check how often they are called, when they are called, or even if they are called at all. This stub behavoir may be defined by using the methods andStubReturn(Object value), andStubThrow(Throwable throwable), andStubAnswer(IAnswer answer) and asStub(). The following code configures the MockObject to answer 42 to voteForRemoval("Document") once and -1 for all other arguments:

    expect(mock.voteForRemoval("Document")).andReturn(42);
expect(mock.voteForRemoval(not(eq("Document")))).andStubReturn(-1);

Nice Mocks

On a Mock Object returned by createMock() the default behavior for all methods is to throw an AssertionError for all unexpected method calls. If you would like a "nice" Mock Object that by default allows all method calls and returns appropriate empty values (0, null or false), use createNiceMock() instead.

Object Methods

The behavior for the three object methods equals(), hashCode() and toString() cannot be changed for Mock Objects created with EasyMock, even if they are part of the interface for which the Mock Object is created.

Checking Method Call Order Between Mocks

Up to this point, we have seen a mock object as a single object that is configured by static methods on the class EasyMock. But many of these static methods just identify the hidden control of the Mock Object and delegate to it. A Mock Control is an object implementing the IMocksControl interface.

So instead of

    IMyInterface mock = createStrictMock(IMyInterface.class);
replay(mock);
verify(mock);
reset(mock);

we may use the equivalent code:

    IMocksControl ctrl = createStrictControl();
IMyInterface mock = ctrl.createMock(IMyInterface.class);
ctrl.replay();
ctrl.verify();
ctrl.reset();

The IMocksControl allows to create more than one Mock Object, and so it is possible to check the order of method calls between mocks. As an example, we set up two mock objects for the interface IMyInterface, and we expect the calls mock1.a() and mock2.a() ordered, then an open number of calls to mock1.c() and mock2.c(), and finally mock2.b() and mock1.b(), in this order:

    IMocksControl ctrl = createStrictControl();
IMyInterface mock1 = ctrl.createMock(IMyInterface.class);
IMyInterface mock2 = ctrl.createMock(IMyInterface.class);
mock1.a();
mock2.a();
ctrl.checkOrder(false);
mock1.c();
expectLastCall().anyTimes();
mock2.c();
expectLastCall().anyTimes();
ctrl.checkOrder(true);
mock2.b();
mock1.b();
ctrl.replay();

Naming Mock Objects

Mock Objects can be named at creation using createMock(String name, Class toMock), createStrictMock(String name, Class toMock) or createNiceMock(String name, Class toMock). The names will be shown in exception failures.

Backward Compatibility

EasyMock 2 contains a compatibility layer so that tests using EasyMock 1.2 for Java 1.5 should work without any modification. The only known differences are visible when failures occur: there are small changes in the failure messages and stack traces, and failures are now reported using Java's AssertionError instead of JUnit's AssertionFailedError.

EasyMock 2.1 introduced a callback feature that has been removed in EasyMock 2.2, as it was too complex. Since EasyMock 2.2, the IAnswer interface provides the functionality for callbacks.

EasyMock Development

EasyMock 1.0 has been developed by Tammo Freese at OFFIS. The development of EasyMock is now hosted on SourceForge to allow other developers and companies to contribute.

Thanks to the people who gave feedback or provided patches, including Nascif Abousalh-Neto, Dave Astels, Francois Beausoleil, George Dinwiddie, Shane Duan, Wolfgang Frech, Steve Freeman, Oren Gross, John D. Heintz, Dale King, Brian Knorr, Dierk Koenig, Chris Kreussling, Robert Leftwich, Patrick Lightbody, Johannes Link, Rex Madden, David McIntosh, Karsten Menne, Bill Michell, Stephan Mikaty, Ivan Moore, Ilja Preuss, Justin Sampson, Markus Schmidlin, Richard Scott, Joel Shellman, Jiří Mareš, Alexandre de Pellegrin Shaun Smith, Marco Struck, Ralf Stuckert, Victor Szathmary, Henri Tremblay, Bill Uetrecht, Frank Westphal, Chad Woolley, Bernd Worsch, and numerous others.

Please check the EasyMock home page for new versions, and send bug reports and suggestions to the EasyMock Yahoo!Group. If you would like to subscribe to the EasyMock Yahoo!Group, send a message to easymock-subscribe@yahoogroups.com.

EasyMock Version 2.3 (July 9 2007)

Changes since 2.2:

• French documentation
• Matchers for Comparable parameters
• Decimal comparison fix
• Mock Objects can now be named
• Include Bill Michell's ThreadLocal fix
• Converted EasyMock's unit tests to JUnit 4

Changes since 2.1:

• answers for expected calls can now be created at call time via andAnswer(IAnswer answer) and andStubAnswer(IAnswer answer)
• callback(Runnable runnable) has been removed, for callbacks, please switch to andAnswer(IAnswer answer) and andStubAnswer(IAnswer answer)
• replay(), verify() and reset() now accept multiple mock objects as arguments

Changes since 2.0:

• arguments passed to the mock object are now available in callbacks via EasyMock.getCurrentArguments()
• fixed bug reported in http://groups.yahoo.com/group/easymock/message/558
• earlier failing if unused matchers were specified

Changes since 1.2:

• support for flexible, refactoring-safe argument matchers
• no mock control is needed for single Mock Objects
• stub behavior replaces default behavior
• support for call order checking for more than one mock, and to switch order checking on and off
• support for callbacks
• EasyMock now throws java.lang.AssertionError instead of junit.framework.AssertionFailedError so that it is now independent from the testing framework, you may use it with JUnit 3.8.x, JUnit 4 and TestNG
• deprecated old API

模拟对象只是模拟领域代码直接的部分行为，能检测是否他们如定义中的被使用。使用 Mock 对象，来模拟合作接口，有助于隔离测试相应的领域类。

创建和维持 Mock 对象经常是繁琐的任务，并且可能会引入错误。 EasyMock 2 动态产生 Mock 对象，不需要创建，并且不会产生代码。

有利的方面：

不需要手工写类来处理 mock 对象。

支持安全的重构 Mock 对象：测试代码不会在运行期打断当重新命名方法或者更改方法参数。

支持返回值和例外。

支持检察方法调用次序，对于一个或者多个 Mock 对象。

不利的方面： 2.0 仅使用于 java 2 版本 5.0 或者以上
    

    以一个例子来说明如何使用EasyMock:
   假设有一个合作接口Collaborator：
           

package org.easymock.samples;   public interface Collaborator {     void documentAdded(String title);     void documentChanged(String title);     void documentRemoved(String title);     byte voteForRemoval(String title);     byte[] voteForRemovals(String[] title); }

            
package org.easymock.samples;

            import java.util.HashMap;

            import java.util.HashSet;

            import java.util.Map;

            import java.util.Set;
            
public class ClassUnderTest {
            
    private Set<Collaborator> listeners = new HashSet<Collaborator>();
            
    private Map<String, byte[]> documents = new HashMap<String, byte[]>();
            
    public void addListener(Collaborator listener) {

                    listeners.add(listener);

                }
            
    public void addDocument(String title, byte[] document) {

                    boolean documentChange = documents.containsKey(title);

                    documents.put(title, document);

                    if (documentChange) {

                        notifyListenersDocumentChanged(title);

                    } else {

                        notifyListenersDocumentAdded(title);

                    }

                }
            
    public boolean removeDocument(String title) {

                    if (!documents.containsKey(title)) {

                        return true;

                    }
            
        if (!listenersAllowRemoval(title)) {

                        return false;

                    }
            
        documents.remove(title);

                    notifyListenersDocumentRemoved(title);
            
        return true;

                }
            
    public boolean removeDocuments(String[] titles) {

                    if (!listenersAllowRemovals(titles)) {

                        return false;

                    }
            
        for (String title : titles) {

                        documents.remove(title);

                        notifyListenersDocumentRemoved(title);

                    }

                    return true;

                }
            
    private void notifyListenersDocumentAdded(String title) {

                    for (Collaborator listener : listeners) {

                        listener.documentAdded(title);

                    }

                }
            
    private void notifyListenersDocumentChanged(String title) {

                    for (Collaborator listener : listeners) {

                        listener.documentChanged(title);

                    }

                }
            
    private void notifyListenersDocumentRemoved(String title) {

                    for (Collaborator listener : listeners) {

                        listener.documentRemoved(title);

                    }

                }
            
    private boolean listenersAllowRemoval(String title) {

                    int result = 0;

                    for (Collaborator listener : listeners) {

                        result += listener.voteForRemoval(title);

                    }

                    return result > 0;

                }
            
    private boolean listenersAllowRemovals(String[] titles) {

                    int result = 0;

                    for (Collaborator listener : listeners) {

                        result += listener.voteForRemovals(titles);

                    }

                    return result > 0;

                }
            
}
            

第一个Mock 对象

            

            
package org.easymock.samples;
            
 
            
import junit.framework.TestCase;
            
 
            
public class ExampleTest extends TestCase {
            
 
            
    private ClassUnderTest classUnderTest;
            
    private Collaborator mock;
            
 
            
    protected void setUp() {
            
        classUnderTest = new ClassUnderTest();
            
        classUnderTest.addListener(mock);
            
    }
            
 
            
    public void testRemoveNonExistingDocument() {    
            
        // This call should not lead to any notification
            
        // of the Mock Object: 
            
        classUnderTest.removeDocument("Does not exist");
            
    }
            
}
            
            

            
 
            
import static org.easymock.EasyMock.*;
            
import junit.framework.TestCase;
            
public class ExampleTest extends TestCase {
            
    private ClassUnderTest classUnderTest;
            
    private Collaborator mock;
            
    
            
}
            
            

            
 
            
protected void setUp() {
            
        mock = createMock(Collaborator.class); // 1
            
        classUnderTest = new ClassUnderTest();
            
        classUnderTest.addListener(mock);
            
    }

            

            
 public void testRemoveNonExistingDocument() {
            
        // 2 (we do not expect anything)
            
        replay(mock); // 3
            
        classUnderTest.removeDocument("Does not exist");
                }
            
            

            
 
            
java.lang.AssertionError: 
            
  Unexpected method call documentRemoved("Does not exist"):
            
    at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:29)
            
    at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44)
            
    at $Proxy0.documentRemoved(Unknown Source)
            
    at org.easymock.samples.ClassUnderTest.notifyListenersDocumentRemoved(ClassUnderTest.java:74)
            
    at org.easymock.samples.ClassUnderTest.removeDocument(ClassUnderTest.java:33)
            
    at org.easymock.samples.ExampleTest.testRemoveNonExistingDocument(ExampleTest.java:24)
            
    ...
            
            

增加行为

            
 
            
 public void testAddDocument() {
            
        mock.documentAdded("New Document"); // 2
            
        replay(mock); // 3
            
        classUnderTest.addDocument("New Document", new byte[0]); 
            
    }
            
            

            
 
            
java.lang.AssertionError: 
            
  Unexpected method call documentAdded("Wrong title"):
            
    documentAdded("New Document"): expected: 1, actual: 0
            
    at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:29)
            
    at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44)
            
    at $Proxy0.documentAdded(Unknown Source)
            
    at org.easymock.samples.ClassUnderTest.notifyListenersDocumentAdded(ClassUnderTest.java:61)
            
    at org.easymock.samples.ClassUnderTest.addDocument(ClassUnderTest.java:28)
            
    at org.easymock.samples.ExampleTest.testAddDocument(ExampleTest.java:30)
            
    ...
            
            

同样，如果调用多次此方法，则也会抛出例外：

            
 
            
java.lang.AssertionError: 
            
  Unexpected method call documentAdded("New Document"):
            
    documentAdded("New Document"): expected: 1, actual: 1 (+1)
            
    at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:29)
            
    at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44)
            
    at $Proxy0.documentAdded(Unknown Source)
            
    at org.easymock.samples.ClassUnderTest.notifyListenersDocumentAdded(ClassUnderTest.java:62)
            
    at org.easymock.samples.ClassUnderTest.addDocument(ClassUnderTest.java:29)
            
    at org.easymock.samples.ExampleTest.testAddDocument(ExampleTest.java:30)
            
    ...
            
            

验证行为

       当我们指定行为后，我们将验证实际发生的。当前的测试将会判断是否Mock对象会真实调用。可以调用verify(mock)来山正是否指定的行为被调用。

            
 
            
public void testAddDocument() {
            
        mock.documentAdded("New Document"); // 2 
            
        replay(mock); // 3
            
        classUnderTest.addDocument("New Document", new byte[0]);
            
        verify(mock);
            
    }
            
            

如果失败，则抛出AssertionError

期待明显数量的调用

到现在，我们的测试只是调用一个简单的方法。下一个测试将会检测是否已经存在document导致mock.documentChanged()调用。为了确认，调用三次

            
 
            
public void testAddAndChangeDocument() {
            
        mock.documentAdded("Document");
            
        mock.documentChanged("Document");
            
        mock.documentChanged("Document");
            
        mock.documentChanged("Document");
            
        replay(mock);
            
        classUnderTest.addDocument("Document", new byte[0]);
            
        classUnderTest.addDocument("Document", new byte[0]);
            
        classUnderTest.addDocument("Document", new byte[0]);
            
        classUnderTest.addDocument("Document", new byte[0]);
            
        verify(mock);
            
    }
            
            

为了避免重复的mock.documentChanged("Document"),EasyMock提供一个快捷方式。可以通过调用方法expectLastCall().times(int times)来指定最后一次调用的次数。

            
 
            
 public void testAddAndChangeDocument() {
            
        mock.documentAdded("Document");
            
        mock.documentChanged("Document");
            
        expectLastCall().times(3);
            
        replay(mock);
            
        classUnderTest.addDocument("Document", new byte[0]);
            
        classUnderTest.addDocument("Document", new byte[0]);
            
        classUnderTest.addDocument("Document", new byte[0]);
            
        classUnderTest.addDocument("Document", new byte[0]);
            
        verify(mock);
            
    }
            
            

指定返回值

       对于指定返回值，我们通过封装expect(T value)返回的对象并且指定返回的值，使用方法andReturn(Object returnValue)于expect(T value).返回的对象。

例如：

            
 
            
public void testVoteForRemoval() {
            
        mock.documentAdded("Document");   // expect document addition
            
        // expect to be asked to vote for document removal, and vote for it
            
        expect(mock.voteForRemoval("Document")).andReturn((byte) 42);
            
        mock.documentRemoved("Document"); // expect document removal
            
        replay(mock);
            
        classUnderTest.addDocument("Document", new byte[0]);
            
        assertTrue(classUnderTest.removeDocument("Document"));
            
        verify(mock);
            
    } 
            
 
            
    public void testVoteAgainstRemoval() {
            
        mock.documentAdded("Document");   // expect document addition
            
        // expect to be asked to vote for document removal, and vote against it
            
        expect(mock.voteForRemoval("Document")).andReturn((byte) -42);
            
        replay(mock);
            
        classUnderTest.addDocument("Document", new byte[0]);
            
        assertFalse(classUnderTest.removeDocument("Document"));
            
       verify(mock);
            
    }
            
            

            
 expect(mock.voteForRemoval("Document")).andReturn((byte) 42);
            

等同于

            
 
            
mock.voteForRemoval("Document");
            
expectLastCall().andReturn((byte) 42);
            
            

处理例外

对于指定的例外(更确切的:Throwables)被抛出，由expectLastCall()和expect(T value)返回的对象，提供了方法andThrow(Throwable throwable)。方法不得不被调用记录状态，在调用Mock对象后，对于此指定了要抛出的Throwable。