/*如果连接池中的缓存连接数大于少缓存连接数，检查释放数据连接后是否
缓存连接数比之前减少了一个，反之缓存连接数是否保持为少缓存连接数
*/
if (cacheSize > minConnections){
assertEquals(cacheSize， cacheSizeAfter + 1);
} else {
assertEquals(cacheSize， minConnections);
}
}
/** 释放建立测试起始环境时的资源。
*/
protected void tearDown() {
cacheImpl = null;
conProxy.destroy();
}
public DefaultConnectionProxyTest(String name) {
super(name);
}
/** 你可以简单的运行这个类从而对类中所包含的测试单元进行测试。
*/
public static void main(String args[]) {
junit.textui.TestRunner.run(DefaultConnectionProxyTest.class);
}
}
当单元测试完成后，我们可以用Junit提供的TestSuite对象对测试单元进行组织，你可以决定测试的顺序，然后运行你的测试。
4. 如何维护单元测试
通过上面的描述，我们对如何确定和编写测试有了基本的了解，但是需求总是变化的，因此我们的单元测试也会根据需求的变化不断的演变。如果我们决定修改类的行为规则，可以明确的是，我们当然会对针对这个类的测试单元进行修改，以适应变化。但是如果对这个类仅有调用关系的类的行为定义没有变化则相应的单元测试仍然是可靠和充分的，同时如果包含行为变化的类的对象的状态定义与其没有直接的关系，测试单元仍然起效。这种结果也是封装原则的优势体现。
关于作者
申文波： 1973年出生，现于艾昂科技上海公司任技术顾问。在关系数据库对象建模方面有较长的工作经验，熟悉Java语言，目前从事的工作领域主要包括OOA、OOD和企业应用。您可以通过邮件alair_china@yahoo.com.cn与他联系。
--------------------------------------------------------------------------------
JUnit 是一个集成测试工具。能实现测试的自动化。
他写的是单元测试：软件工程里的白盒测试，是测试某个类的某个方法的功能。
XP 中推崇的 test first design 是基于以上的技术
如果你要写一段代码：
先用 junit 写测试，然后再写代码
写完代码，运行测试，测试失败
修改代码，运行测试，直到测试成功
如果以后对程序进行修改，优化 ( refactoring )，只要再运行测试代码
如果所有的测试都成功，则代码修改完成。
Java 下的 team 开发，一般采用 cvs(版本控制) + ant(项目管理) + junit(集成测试) 的模式：
每天早上上班，每个开发人员从 cvs server 获取一个整个项目的工作拷贝。
拿到自己的任务，先用 junit 写的任务的测试代码。
然后写任务的代码，运行测试，直到测试通过，任务完成
在下班前一两个小时，各个开发人员把任务提交到 cvs server
然后由主管对整个项目运行自动测试，哪个测试出错，找相关人员修改，直到所有测试通过。下班。。。
先写测试，再写代码的好处：
从技术上强制你先考虑一个类的功能，也是这个类提供给外部的接口，而不至于太早
陷入它的细节。这是面向对象提倡的一种设计原则。
好的测试其实是一个好的文档，这个类使用者往往可以通过查看这个类的测试代码了
解它的功能。特别的，如果你拿到别人的一个程序，对他写测试是好的了解这个程序
的功能的方法。 xp的原则是 make it simple，不是很推荐另外写文档，因为项目在开
发过程中往往处于变动中，如果在早期写文档，以后代码变动后还得同步文档，多了一
个工作，而且由于项目时间紧往往文档写的不全或与代码不一致，与其这样，不如不写。
而如果在项目结束后再写文档，开发人员往往已经忘记当时写代码时的种种考虑，况且
有下一个项目的压力，管理人员也不愿意再为旧的项目写文档。导致以后维护的问题。
没有人能保证需求不变动，以往项目往往对需求的变动大为头疼，害怕这个改动会带来
其他地方的错误。为此，除了设计好的结构以分割项目外（松耦合），但如果有了测试，
并已经建立了一个好的测试框架，对于需求的变动，修改完代码后，只要重新运行测试
代码，如果测试通过，也保证了修改的成功，如果测试中出现错误，也会马上发现错
在哪里。修改相应的部分，再运行测试，直至测试完全通过。
软件公司里往往存在开发部门和测试部门之间的矛盾：由于开发和测试分为两个部门，
多了一层沟通的成本和时间，沟通往往会产生错误的发生。而且极易形成一个怪圈：开
发人员为了赶任务，写了烂烂的代码，把它扔给测试人员，然后写其他的任务，测试
当然是失败的，又把代码拿回去重写，而且在国内往往一个软件公司技术差的部门
是测试部门（好的人都跑去写代码了），测试成了一个很头疼的问题。这种怪圈的根
源是责任不清，根据 xp 中的规定：写这个代码的人必须为自己的代码写测试，而且只
有测试通过，才算完成这个任务（这里的测试包括所有的测试，如果测试时发现由于你
的程序导致别的模块的测试失败，你有责任通知相关人员修改直至集成测试通过），这
样可以避免这类问题的发生。
