junit的意义

写了这么久代码了，自己从来没有好好的玩过junit。马上过年了，打算趁这段时间自己来写一套web框架，但是这里有一个很大的尴尬就是我平时编码并没有认真的来写测试类。那么自己在写框架的时候，不测试肯定是不好的，一点保障都没有了。所以在写框架之前，还是要认真的好好的研究下junit。在这里为喜欢junit而且不幸读到本人这一系列文章的人推荐2本书：junit实战+有效的单元测试。这2本书都挺好的，值得一看。我也是基于这2本书来整理junit系列内容。

OK，言归正传，开始步入正题。

• 为什么要使用junit？

这个问题我觉得很有必要这里拉出来讨论半天，因为就我自己的切身经验而讲，junit最大的用处就是代码建模。我以前看过TTD相关的资料，对于测试驱动开发带来的代码结构上的优势也是比较有心得的。至于其他比如说代码的健壮性，代码的功能性等等我觉得其实收获不大，不管我们开发的自测还是测试人员的测试我觉得基本的功能都差不多能跑，但是代码如果是一坨屎的话，这的确是一个很恶心的事情。所以我们要基于给测试提供便利来编码正常代码，那么这个时候我们的代码结构就会好很大，以后的代码维护量也变得更加合理。其实关于测试的意义，还有测试驱动开发的种种原因好多资料有大量的介绍，说句最实在的话，如果这个东西写的不好或者说没有太大必要的话，也不会这么主流，对吧。所以存在即合理，真正被发扬光大肯定是有足够的原因的。


OK，现在我们这里引入一个不使用和使用junit的例子来开篇junit系列。
现在我们写一个工具类，就写一个关于计算的类吧。代码如下：

package juint.main;


/**
 * @创建作者： LinkinPark
 * @创建时间： 2016年1月9日
 * @功能描述： 一个计算类
 */
public class Calculater
{


	// 一个加法计算
	public static double add(double numberA, double numberB)
	{
		return numberA + numberB;
	}


}

上面的代码很简单，我们这里不再啰嗦为什么测试的意义，别动不动就说这么简单的代码不需要测试，千里之行还始于足下呢。OK，现在开始为该类编写测试。
OK，如果我们不使用单元测试，一般都是自己写一个main方法来进行测试。代码如下：

package juint.main;


/**
 * @创建作者： LinkinPark
 * @创建时间： 2016年1月9日
 * @功能描述： 计算类相关测试类
 */
public class CalculaterTest
{
	public static void main(String[] args)
	{
		Double result = Calculater.add(1, 2);
		if (result != 3)
		{
			System.out.println("测试不通过，因为结果出错了呢");
		}
		else
		{
			System.out.println("测试通过了，但是这个时候必须要去控制台去看了呢");
		}
	}


}

上面的代码表面上看没一点问题，但是现在我们一点都没有考虑代码向后兼容性。如果我们写多个方法的话连一起测试都不可以，连成功了个数和失败了的个数都不知道，这也太土了。那OK，我们现在换一种思路，用Java中的异常来处理测试不通过的情况；代码如下：

package juint.main;


/**
 * @创建作者： LinkinPark
 * @创建时间： 2016年1月9日
 * @功能描述： 计算类相关测试类
 */
public class CalculaterTest
{
	private static int errors = 0;


	public static void main(String[] args)
	{
		try
		{
			add();
		}
		catch (IllegalAccessException e)
		{
			errors++;
			e.printStackTrace();
		}
		if (errors > 0)
		{
			System.out.println("一共有" + errors + "错误");
		}
	}


	private static void add() throws IllegalAccessException
	{
		Double result = Calculater.add(1, 2);
		if (result != 3)
		{
			throw new IllegalAccessException("测试没通过。。。");
		}
	}


}

现在的代码好了一点了，但是仍然存在3个问题：
1，不管说测试有没有通过，我们都要必须去顶着控制台去看，然后找出我们自己写的那些输入，很麻烦
2，我们如果写多个测试类或者测试方法，那么我们希望各个测试单元就不应该互相影响。为了使每个单元测试都能够真正独立运行，就应该在不同的类实例中运行他们，理想情况就是在不同的类加载器实例中运行他们。
3，如果我们不小心就很有可能遗漏掉了某些测试而且这个时候我们还不知道，或者说我们也没有办法人工来控制说那些测试执行和和那些测试不执行，这是一个很严重的设计上的问题。


上面我们的程序一些不起眼的改进就突出体现了所有单元测试框架应该遵循的三大规则：
1，每个单元测试都必须独立于其他所有单元测试而运行
2，框架应该以单个测试为单位来检测和报告错误
3，应该易于定义要运行那些单元测试。


本篇主要强调下了测试的意义，最后这里我以junit的设计目标来结束这篇博客：

• junit有3大设计目标：

1，框架必须帮助我们编写有用的测试
2，框架必须帮助我们创建具有长久价值的测试
3，框架必须帮助我们通过服用代码来降低编写测试的成本。