私有化方法如何单元测试

1. 单元测试是什么简单介绍一下单元测试

工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。
其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，老纳把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。
对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。
要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。老纳认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈老纳的看法。
一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以老纳的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。
有一种看法是，只测试类的接口(公有函数)，不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写(inline函数)，所有在源文件编写实现的函数都要进行测试(构造函数和析构函数除外)。
什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。
由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。
关于桩代码，老纳认为，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。

2. Spring Boot 微服务异步调用 @EnableAsync @Async

第一步：在Application启动类上面加上@EnableAsync注解

第二步：定义[线程池]

第三步：在异步方法上添加@Async

第四步：测试

输出结果：

时间testA：2
开始testB
开始testA
完成testA
完成testB
任务testA，当前线程：async-thread-pool-1
时间testB：3002
异步方法@Async注解失效情况：

（1）在@SpringBootApplication启动类没有添加注解@EnableAsync

（2）调用方法和异步方法写在同一个类，需要在不同的类才能有效。

（2）调用的是静态(static )方法

（3）调用(private)私有化方法

个别失效报错情况：

报错一：提示需要在@EnableAsync上设置proxyTargetClass=true来强制使用基于cglib的代理。注解上加上即可。

3. 求问浅谈:怎么为私有方法写单元测试

• 为私有方法写单元测试：new一个对象，设好入口参数后，调用这个方法，比较期望值和实际值即可。给一个类的私有方法做单元测试，也不麻烦，先通过反射获取这个方法，然后将这个方法的可访问性强制设为true，这样的话，这个私有方法就可以被调用了。

• 代码如下：

//被测试方法

private Double format(Double fileSize){

Double size = fileSize;

size = size / 1024 / 1024;

size = (int)(size.doubleValue() * 10 + 0.5) / 10.0;

return size;

}

@Test

public void testFormat(){

ClientDownloadAction action = new ClientDownloadAction();

double size = 3732930;

Class class1 = action.getClass();

try {

Method format = class1.getDeclaredMethod("format", Double.class);

format.setAccessible(true);//设为可见

Double result = (Double)format.invoke(action, size);

Double expect = 3.6;

Assert.assertEquals(expect, result);

} catch (Exception e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}

4. Java，私有方法做Junit单元测试，私有方法中注入了其他的bean，运行时，这个bean为空，没有注入

这种情况一般有仿真程序来实现。junit有很多扩展的包。例如dbunit等。

5. private className(){}单元测试如何覆盖

我们知道可以通过反射method.invoke来调用某个方法，但如果方法前面为private怎么办呢？我们可以使用method.setAccessible(true);来跳过安全检查，就可以调用private方法了。原理就这么简单。
Java的反射（reflection）机制是指在程序的运行状态中，可以构造任意一个类的对象，可以了解任意一个对象所属的类，可以了解任意一个类的成员变量和方法，可以调用任意一个对象的属性和方法。这种动态获取程序信息以及动态调用对象的功能称为Java语言的反射机制。反射被视为动态语言的关键。

6. 怎样使用Junit Framework进行单元测试的编写

1. 单元测试的编写原则

Junit 附带文档所列举的单元测试带有一定的迷惑性，因为几乎所有的示例单元都是针对某个对象的某个方法，似乎 Junit 的单元测试仅适用于类组织结构的静态约束，从而使初学者怀疑 Junit 下的单元测试所能带来的效果。因此我们需要重新定义如何确定有价值的单元测试以及如何编写这些单元测试、维护这些单元测试，从而让更多的程序员接受和熟悉 Junit 下的单元测试的编写。
在 Junit 单元测试框架的设计时，作者一共设定了三个总体目标，第一个是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；第二个是使测试单元保持持久性；第三个则是可以利用既有的测试来编写相关的测试。从这三个目标可以看出，单元测试框架的基本设计考虑依然是从我们现有的测试方式和方法出发，而只是使测试变得更加容易实施和扩展并保持持久性。因此编写单元测试的原则可以从我们通常使用的测试方法借鉴和利用。
回页首
2. 如何确定单元测试
在我们通常的测试中，一个单元测试一般针对于特定对象的一个特定特性，譬如，假定我们编写了一个针对特定数据库访问的连接池的类包实现，我们会建立以下的单元测试：
在连接池启动后，是否根据定义的规则在池中建立了相应数量的数据库连接
申请一个数据库连接，是否根据定义的规则从池中直接获得缓存连接的引用，还是建立新的连接
释放一个数据库连接后，连接是否根据定义的规则被池释放或者缓存以便以后使用
后台 Housekeeping 线程是否按照定义的规则释放已经过期的连接申请
如果连接有时间期限，后台 Housekeeping 线程是否定期释放已经过期的缓存连接
这儿只列出了部分的可能测试，但是从这个列表我们可以看出单元测试的粒度。一个单元测试基本是以一个对象的明确特性为基础，单元测试的过程应该限定在一个明确的线程范围内。根据上面所述，一个单元测试的测试过程非常类似于一个 Use Case 的定义，但是单元测试的粒度一般来说比 Use Case 的定义要小，这点是容易理解的，因为 Use Case 是以单独的事务单元为基础的，而单元测试是以一组聚合性很强的对象的特定特征为基础的，一般而言一个事务中会利用许多的系统特征来完成具体的软件需求。
从上面的分析我们可以得出，测试单元应该以一个对象的内部状态的转换为基本编写单元。一个软件系统就和一辆设计好的汽车一样，系统的状态是由同一时刻时系统内部的各个分立的部件的状态决定的，因此为了确定一个系统最终的行为符合我们起始的要求，我们首先需要保证系统内的各个部分的状态会符合我们的设计要求，所以我们的测试单元的重点应该放在确定对象的状态变换上。
然而需要注意的并不是所有的对象组特征都需要被编写成独立的测试单元，如何在对象组特征里筛选有价值的测试单元的原则在 JUnitTest Infected: Programmers Love Writing Tests 一文中得到了正确的描述，你应该在有可能引入错误的地方引入测试单元，通常这些地方存在于有特定边界条件、复杂算法以及需求变动比较频繁的代码逻辑中。除了这些特性需要被编写成独立的测试单元外，还有一些边界条件比较复杂的对象方法也应该被编写成独立的测试单元，这部分单元测试已经在 Junit 文档中被较好的描述和解释过了。
在基本确定了需要编写的单元测试，我们还应该问自己：编写好了这些测试，我们是否可以有把握地告诉自己，如果代码通过了这些单元测试，我们能认定程序的运行是正确的，符合需求的。如果我们不能非常的确定，就应该看看是否还有遗漏的需要编写的单元测试或者重新审视我们对软件需求的理解。通常来说，在开始使用单元测试的时候，更多的单元测试总是没有错的。
一旦我们确定了需要被编写的测试单元，接下来就应该
回页首
3. 如何编写单元测试
在 XP 下强调单元测试必须由类包的编写者负责编写，这个限定对于我们设定的测试目标是必须的。因为只有这样，测试才能保证对象的运行时态行为符合需求，而仅通过类接口的测试，我们只能确保对象符合静态约束，因此这就要求我们在测试的过程中，必须开放一定的内部数据结构，或者针对特定的运行行为建立适当的数据记录，并把这些数据暴露给特定的测试单元。这也就是说我们在编写单元测试时必须对相应的类包进行修改，这样的修改也发生在我们以前使用的测试方法中，因此以前的测试标记及其他一些测试技巧仍然可以在 Junit 测试中改进使用。
由于单元测试的总体目标是负责我们的软件在运行过程中的正确无误，因此在我们对一个对象编写单元测试的时候，我们不但需要保证类的静态约束符合我们的设计意图，而且需要保证对象在特定的条件下的运行状态符合我们的预先设定。还是拿数据库缓冲池的例子说明，一个缓冲池暴露给其他对象的是一组使用接口，其中包括对池的参数设定、池的初始化、池的销毁、从这个池里获得一个数据连接以及释放连接到池中，对其他对象而言随着各种条件的触发而引起池的内部状态的变化是不需要知道的，这一点也是符合封装原理的。但是池对象的状态变化，譬如：缓存的连接数在某些条件下会增长，一个连接在足够长的运行后需要被彻底释放从而使池的连接被更新等等，虽然外部对象不需要明确，但是却是程序运行正确的保证，所以我们的单元测试必须保证这些内部逻辑被正确的运行。
编译语言的测试和调试是很难对运行的逻辑过程进行跟踪的，但是我们知道，无论逻辑怎么运行，如果状态的转换符合我们的行为设定，那验证结果显然是正确的，因此在对一个对象进行单元测试的时候，我们需要对多数的状态转换进行分析和对照，从而验证对象的行为。状态是通过一系列的状态数据来描述的，因此编写单元测试首先分析出状态的变化过程（状态转换图对这个过程的描述非常清晰），然后根据状态的定义确定分析的状态数据，最后是提供这些内部的状态数据的访问。在数据库连接池的例子中，我们对池实现的对象 DefaultConnectionProxy 的状态变换进行分析后，我们决定把表征状态的 OracleConnectionCacheImpl 对象公开给测试类。参见示例一
示例一
/**
* 这个类简单的包装了 oracle 对数据连接缓冲池的实现。
*
*/
public class DefaultConnectionProxy extends ConnectionProxy {
private static final String name = "Default Connection Proxy";
private static final String description =
"这个类简单的包装了 oracle 对数据连接缓冲池的实现。";
private static final String author = "Ion-Global.com";
private static final int major_version = 0;
private static final int minor_version = 9;
private static final boolean pooled = true;
private ConnectionBroker connectionBroker = null;
private Properties props;
private Properties propDescriptions;
private Object initLock = new Object();
// Test Code Begin...
/* 为了能够了解对象的状态变化，因此需要把表征对象内部状态变化的部分私有变量提
供公共的访问接口（或者提供让同一个类包的访问接口），以便使测试单元可以有效地
判断对象的状态转变，在本示例中对包装的 OracleConnectionCacheImpl 对象提供访问
接口。
*/
OracleConnectionCacheImpl getConnectionCache() {
if (connectionBroker == null) {
throw new IllegalStateException("You need start the server first.");
}

return connectionBroker.getConnectionCache();
}
// Test Code End...

在公开内部状态数据后，我们就可以编写我们的测试单元了，单元测试的选择方法和选择尺度已经在本文前面章节进行了说明，但是仍然需要注意的是，由于 assert 方法会抛出一个 error，你应该在测试方法的最后集中用 assert 相关方法进行判断，这样可以确保资源得到释放。
对数据库连接池的例子，我们可以建立测试类 DefaultConnectionProxyTest，同时建立数个 test case，如下：
示例二
/**
* 这个类对示例一中的类进行简单的测试。
*
*/
public class DefaultConnectionProxyTest extends TestCase {
private DefaultConnectionProxy conProxy = null;
private OracleConnectionCacheImpl cacheImpl = null;
private Connection con = null;
/** 设置测试的 fixture，建立必要的测试起始环境。
*/
protected void setUp() {
conProxy = new DefaultConnectionProxy();
conProxy.start();
cacheImpl = conProxy.getConnectionCache();
}
/** 对示例一中的对象进行服务启动后的状态测试，检查是否在服务启动后，
连接池的参数设置是否正确。
*/
public void testConnectionProxyStart() {
int minConnections = 0;
int maxConnections = 0;
assertNotNull(cacheImpl);
try {
minConnections = Integer.parseInt(PropertyManager.getProperty
("DefaultConnectionProxy.minConnections"));
maxConnections = Integer.parseInt(PropertyManager.getProperty
("DefaultConnectionProxy.maxConnections"));
} catch (Exception e) {
// ignore the exception
}
assertEquals(cacheImpl.getMinLimit(), minConnections);
assertEquals(cacheImpl.getMaxLimit(), maxConnections);
assertEquals(cacheImpl.getCacheSize(), minConnections);
}
/** 对示例一中的对象进行获取数据库连接的测试，看看是否可以获取有效的数据库连接，
并且看看获取连接后，连接池的状态是否按照既定的策略进行变化。由于 assert 方法抛出的是
error 对象，因此尽可能把 assert 方法放置到方法的最后集体进行测试，这样在方法内打开的
资源，才能有效的被正确关闭。
*/
public void testGetConnection() {
int cacheSize = cacheImpl.getCacheSize();
int activeSize = cacheImpl.getActiveSize();
int cacheSizeAfter = 0;
int activeSizeAfter = 0;
con = conProxy.getConnection();
if (con != null) {
activeSizeAfter = cacheImpl.getActiveSize();
cacheSizeAfter = cacheImpl.getCacheSize();

try {
con.close();
} catch (SQLException e) {
}
} else {
assertNotNull(con);
}
/* 如果连接池中的实际使用连接数小于缓存连接数，检查获取的新的数据连接是否
从缓存中获取，反之连接池是否建立新的连接
*/
if (cacheSize > activeSize) {
assertEquals(activeSize + 1, activeSizeAfter);
assertEquals(cacheSize, cacheSizeAfter);
} else {
assertEquals(activeSize + 1, cacheSizeAfter);
}
}
/** 对示例一中的对象进行数据库连接释放的测试，看看连接释放后，连接池的
状态是否按照既定的策略进行变化。由于 assert 方法抛出的是 error 对象，因此尽可
能把 assert 方法放置到方法的最后集体进行测试，这样在方法内打开的
资源，才能有效的被正确关闭。
*/
public void testConnectionClose() {
int minConnections = cacheImpl.getMinLimit();
int cacheSize = 0;
int activeSize = 0;
int cacheSizeAfter = 0;
int activeSizeAfter = 0;
con = conProxy.getConnection();
if (con != null) {
cacheSize = cacheImpl.getCacheSize();
activeSize = cacheImpl.getActiveSize();
try {
con.close();
} catch (SQLException e) {
}
activeSizeAfter = cacheImpl.getActiveSize();
cacheSizeAfter = cacheImpl.getCacheSize();
} else {
assertNotNull(con);
}
assertEquals(activeSize, activeSizeAfter + 1);
/* 如果连接池中的缓存连接数大于最少缓存连接数，检查释放数据连接后是否
缓存连接数比之前减少了一个，反之缓存连接数是否保持为最少缓存连接数
*/
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 对象对测试单元进行组织，你可以决定测试的顺序，然后运行你的测试。

7. 软件工程单元测试应该怎么写

。。。。。。。。。。。。。。。。

8. 单元测试的测试工具

现在开始介绍单元测试工具，分别按编程语言进行分组介绍。 CppUnit
首先是CppUnit，这是C++单元测试工具的鼻祖，免费的开源的单元测试框架。由于已有一众高人写了不少关于CppUnit的很好的文章，老纳就不现丑了，想了解CppUnit的朋友，建议读一下Cpluser 所作的《CppUnit测试框架入门》，。该文也提供了CppUnit的下载地址。
C++Test
然后介绍C++Test，这是Parasoft公司的产品。[C++Test是一个功能强大的自动化C/C++单元级测试工具，可以自动测试任何C/C++函数、类，自动生成测试用例、测试驱动函数或桩函数，在自动化的环境下极其容易快速的将单元级的测试覆盖率达到100%]。[]内的文字引自，这是华唐公司的网页。老纳想写些介绍C++Test的文字，但发现无法超越华唐公司的网页上的介绍，所以也就省点事了，想了解C++Test的朋友，建议访问该公司的网站。华唐公司代理C++Test，想要购买或索取报价、试用版都可以找他们。
Visual Unit
最后介绍Visual Unit，简称VU，这是国产的单元测试工具，据说申请了多项专利，拥有一批创新的技术，不过老纳只关心是不是有用和好用。[自动生成测试代码 快速建立功能测试用例程序行为一目了然 极高的测试完整性 高效完成白盒覆盖 快速排错 高效调试 详尽的测试报告]。[]内的文字是VU开发商的网页上摘录的，。前面所述测试要求：完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖，用VU可以轻松实现，还有一点值得一提：使用VU还能提高编码的效率，总体来说，在完成单元测试的同时，编码调试的时间还能大幅度缩短。算了，不想再讲了，老纳显摆理论、介绍经验还是有兴趣的，因为可以满足老纳好为人师的虚荣心，但介绍工具就觉得索然无味了，毕竟工具好不好用，合不合用，要试过才知道，还是自己去开发商的网站看吧，可以下载演示版，还有演示课件。
gtest
gtest测试框架是在不同平台上（Linux，Mac OS X，Windows，Cygwin，Windows CE和Symbian）为编写C++测试而生成的。它是基于xUnit架构的测试框架，支持自动发现测试，丰富的断言集，用户定义的断言，death测试，致命与非致命的失败，类型参数化测试，各类运行测试的选项和XML的测试报告。需要详细了解的朋友可以参阅《玩转Google单元测试框架gtest系列》该篇文章。 JUnit
JUnit 是 Java 社区中知名度最高的单元测试工具。它诞生于 1997 年，由 Erich Gamma 和 Kent Beck 共同开发完成。其中 Erich Gamma 是经典着作《设计模式：可复用面向对象软件的基础》一书的作者之一，并在 Eclipse 中有很大的贡献；Kent Beck 则是一位极限编程（XP）方面的专家和先驱。JUnit 设计的非常小巧，但是功能却非常强大。JUnit ——是一个开发源代码的Java测试框架，用于编写和运行可重复的测试。他是用于单元测试框架体系xUnit的一个实例（用于java语言）。主要用于白盒测试，回归测试。
JUnit的好处和JUnit单元测试编写原则：
好处：可以使测试代码与产品代码分开；针对某一个类的测试代码通过较少的改动便可以应用于另一个类的测试；易于集成到测试人员的构建过程中，JUnit和Ant的结合可以实施增量开发；JUnit是公开源代码的，可以进行二次开发；可以方便地对JUnit进行扩展；
编写原则：是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；是使测试单元保持持久性；是可以利用既有的测试来编写相关的测试；
JUnit使用帮助
1、junit3.x版本，我们通常使用junit 3.8
(1)、使用junit3.x版本进行单元测试时，测试类必须要继承于TestCase父类；
(2)、测试方法需要遵循的原则：
A、public的
B、void的
C、无方法参数
D、方法名称必须以test开头
(3)、不同的Test Case之间一定要保持完全的独立性，不能有任何的关联。
(4)、我们要掌握好测试方法的顺序，不能依赖于测试方法自己的执行顺序。
dome:
public class TestMyNumber extends TestCase {
private MyNumber myNumber;
public TestMyNumber(String name) {
super(name);
}
// 在每个测试方法执行 [之前] 都会被调用
@Override
public void setUp() throws Exception {
// System.out.println(欢迎使用Junit进行单元测试…);
myNumber = new MyNumber();
}
// 在每个测试方法执行 [之后] 都会被调用
@Override
public void tearDown() throws Exception {
// System.out.println(Junit单元测试结束…);
}
public void testDivideByZero() {
Throwable te = null;
try {
myNumber.divide(6, 0);
Assert.fail(测试失败);
} catch (Exception e) {
e.printStackTrace();
te = e;
}
Assert.assertEquals(Exception.class, te.getClass());
Assert.assertEquals(除数不能为 0 , te.getMessage());
}
}
2、junit4.x版本
(1)、使用junit4.x版本进行单元测试时，不用测试类继承TestCase父类，因为，junit4.x全面引入了Annotation来执行我们编写的测试。
(2)、junit4.x版本，引用了注解的方式，进行单元测试；
(3)、junit4.x版本我们常用的注解：
A、@Before 注解：与junit3.x中的setUp()方法功能一样，在每个测试方法之前执行；
B、@After 注解：与junit3.x中的tearDown()方法功能一样，在每个测试方法之后执行；
C、@BeforeClass 注解：在所有方法执行之前执行；
D、@AfterClass 注解：在所有方法执行之后执行；
E、@Test(timeout = xxx) 注解：设置当前测试方法在一定时间内运行完，否则返回错误；
F、@Test(expected = Exception.class) 注解：设置被测试的方法是否有异常抛出。抛出异常类型为：Exception.class；
G、@Ignore 注解：注释掉一个测试方法或一个类，被注释的方法或类，不会被执行。
dome:
package com.an.junit;
import static org.junit.Assert.*;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
public class TestMyNumber {
private MyNumber myNumber;
@BeforeClass
// 在所有方法执行之前执行
public static void globalInit() {
System.out.println(init all method...);
}
@AfterClass
// 在所有方法执行之后执行
public static void globalDestory() {
System.out.println(destory all method...);
}
@Before
// 在每个测试方法之前执行
public void setUp() {
System.out.println(start setUp method);
myNumber = new MyNumber();
}
@After
// 在每个测试方法之后执行
public void tearDown() {
System.out.println(end tearDown method);
}
@Test(timeout=600)// 设置限定测试方法的运行时间 如果超出则返回错误
public void testAdd() {
System.out.println(testAdd method);
int result = myNumber.add(2, 3);
assertEquals(5, result);
}
@Test
public void testSubtract() {
System.out.println(testSubtract method);
int result = myNumber.subtract(1, 2);
assertEquals(-1, result);
}
@Test
public void testMultiply() {
System.out.println(testMultiply method);
int result = myNumber.multiply(2, 3);
assertEquals(6, result);
}
@Test
public void testDivide() {
System.out.println(testDivide method);
int result = 0;
try {
result = myNumber.divide(6, 2);
} catch (Exception e) {
fail();
}
assertEquals(3, result);
}
@Test(expected = Exception.class)
public void testDivide2() throws Exception {
System.out.println(testDivide2 method);
myNumber.divide(6, 0);
fail(test Error);
}
public static void main(String[] args) {
}
}
有兴趣的朋友可以下下来仔细研究下，也可以到安安DIY创作室博客一起讨论一下。
JUnit-addons
对JUnit的一些补充，比如设置、获取被测试对象的私有属性的值，调用被测试对象的私有方法等。
常用类：junitx.util.PrivateAccessor
Spring 测试框架
可以测试基于Spring的应用，通过配置文件和注解自动组装需要的单元测试对象。
提供了一些常用的J2EE Mock对象，比如HttpSession的Mock类等。
可以支持数据库自动回滚，以防止对数据库的单元测试（插入，删除等）不可重复执行，防止修改数据库状态等。
DJUnit
通过代码自动产生Mock对象，省去了自己手动编写N多的Mock类。
此外，它的Eclipse插件还可以做到测试覆盖率、分支统计。
EasyMock
功能同DJUnit，也是通过编程自动Mock掉与测试对象无关的类，方法。