LinkinPark的博客

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

原文出处：http://www.cnblogs.com/caoyuanzhanlang/p/3530267.html。感谢作者的无私分享。Junit是一个可编写重复测试的简单框架，是基于Xunit架构的单元测试框架的实例。Junit4最大的改进是大量使用注解（元数据），很多实际执行过程都在Junit的后台做完了，而且写test case 的类不需要继承TestCase，只需要在

原文出处：http://www.cnblogs.com/caoyuanzhanlang/p/3534846.html。感谢作者的无私分享。前一篇文章我们总体介绍了Junit4的用法以及一些简单的测试。之前我有个疑惑，Junit4怎么把一个test case跑起来的，在test case之前和之后我们能做些什么？Junit4执行顺序是怎样的？带着这些问题，我写了这篇文章，仅供参考，不

原文出处：http://www.blogjava.net/DLevin/archive/2012/05/12/377960.html。感谢作者无私分享到目前，JUnit4所有的核心源码都已经讲解过了，最后剩下的就是为了兼容性而引入的和JUnit3相关的代码以及Assert中的代码。本节将关注于Assert代码。在JUnit4中，对Assert还引入了hamcrest框架的支持，以使断言可读

OK，在前面的一系列博客里面，我整理过了Assert类下面常用的断言方法，比如assertEquals等等，但是org.junit.Assert类下还有一个方法也用来断言，而且更加强大。这就是我们这里要这里的：Assert的AssertThat()方法和Hamcrest匹配器1，断言抛出的异常2，现在让我们来认真的看下AssertThat()和Hamcrest匹配器吧

本文内容摘自junit实战，感谢作者的无私奉献。个人觉得每个开源包的版本对比意义不大，闲来无事，这里就来整理一下好了。本文名为junit3对比junit4，但是我通过这篇博客主要也是想统一的来整理下junit4的一些功能。OK，不废话了，现在我们开始：1，版本的向前兼容和向后兼容所有的junit4测试执行器runner都能够执行junit3测试，代码不需要进行任何修改。但是使用juni

JUnit 的概念及用途JUnit 是由 Erich Gamma 和 Kent Beck 编写的一个开源的单元测试框架。它属于白盒测试，只要将待测类继承 TestCase 类，就可以利用 JUnit 的一系列机制进行便捷的自动测试了。JUnit 的设计精简，易学易用，但是功能却非常强大，这归因于它内部完善的代码结构。 Erich Gamma 是著名的 GOF 之一，因此 JUnit 中深深

OK，我们接着上篇整理。上篇博客中已经列出的junit的几个核心的类，这里我们开始整理junit完整的生命周期。JUnit 的完整生命周期分为 3 个阶段：初始化阶段、运行阶段和结果捕捉阶段。这篇这里先来整理下junit的初始化阶段。也就是创建 Testcase 及 TestSuite。先来贴出junit测试框架入口：/** * @创建时间： 2016年1月21日

使用过spring，然后我们都知道如何使用spring的junit扩展来进行测试，所以我觉得很有必要研究下自定义运行器。比如下面的代码：@RunWith(SpringJUnit4ClassRunner.class)@ContextConfiguration({ "/spring-mvc-servlet.xml", "/applicationContext-db.xml" })@WebApp

前面的博客里面我们已经整理了junit的初始化阶段，接下来就是junit的测试驱动运行阶段，也就是运行所有的testXXX方法。OK，现在我们开始吧。前面初始化junit之后，开始执行doRun方法。Test suite = getTest(testCase); return doRun(suite, wait);doRun()方法的代码如下：/** * @创建时间： 201

OK，前面的博客我们整理了junit运行完了所有的测试用例，那么OK了，现在开始该收集测试结果了。在这最后一步中，junit主要是玩一个类，TestResult。这里类中封装了几个参数，在初始化这个类的时候赋初始值：protected List fFailures; // 失败结果集 protected List fErrors; // 错误结果集 protected List fLi

在junit4X之前的版本，测试的API都是基于继承junit.framework.TestCase的测试类，所以扩展junit要覆盖某些继承行为。junit4X系列之后junit采用注解的方式，所以我们来扩展junit的时候也就多了一种选择。扩展内置的junit行为的主要相关概念是运行器和规则。尽管我们不大会深入自定义插件，但是我们还是应该意识到哪些插件是内置的，以及如何开始编写自定义插件。

这里就先目前阶段，整理一份TDD的最佳实践，在之后的Xunit测试整理中，这份实践会越来越长，对于这份核心在写测试的时候应该时刻注意。1，在软件开发领域中，从来没有这样的事情：少数的几行代码对大量的代码起着如此重要的作用。这就是测试的意义。2，junit与项目管理工具，比如maven，ant的整合，会让我们的测试如虎添翼。之后maven的整理我会详细介绍这块。3，对于doubl

OK，前面的博客整理了一系列的junit相关内容，这里举一个例子TDD实际的编码例子，不管实际编码中是否使用TDD，个人觉得这种思想必须要有。我们不一定在写业务代码之前一定要说是把测试类都写出来，至少脑子里面都应该试试考虑到自己写的一段编码的代码可测性。如果每段代码都可以测试，那么我们可以高枕无忧放心的编码了。那我们现在开始吧。这里举一个简单的业务层代码，对一个用户实现CRUD，然后该业务

前面的博客我们也已经整理到了，我们使用junit38，在写测试类的时候我们的测试类必须继承TestCase。这个所有测试类的父类在junit.framework包下面。前面我们的整理都是说直接在IDE中直接运行测试类，右击然后run as junit。当然我们还可以自己写main方法来运行测试，其实都一样。OK，现在我们来写一个例子，直接运行测试类的main方法来跑测试。代码如下：pa

在实际项目中，随着项目进度的开展，单元测试类会越来越多，可是直到现在我们还只会一个一个的单独运行测试类，这在实际项目实践中肯定是不可行的。为了解决这个问题，JUnit 提供了一种批量运行测试类的方法，叫做测试套件。这样，每次需要验证系统功能正确性时，只执行一个或几个测试套件便可以了。测试套件的写法非常简单，我们需要遵循以下规则：1.  创建一个空类作为测试套件的入口。2.  使用注解

原文出处：http://www.blogjava.net/DLevin/archive/2012/11/02/390684.html。感谢作者的无私分享。说来惭愧，虽然之前已经看过JUnit的源码了，也写了几篇博客，但是长时间不写Test Case，今天想要写抛Exception相关的test case时，竟然不知道怎么写了。。。。。好记性不如烂笔头，记下来先～～对于使用验证Test

原文出处：http://www.blogjava.net/DLevin/archive/2012/05/12/377957.html。感谢作者的无私分享。初次用文字的方式记录读源码的过程，不知道怎么写，感觉有点贴代码的嫌疑。不过中间还是加入了一些自己的理解和心得，希望以后能够慢慢的改进，感兴趣的童鞋凑合着看吧，感觉JUnit这个框架还是值得看的，里面有许多不错的设计思想在，更何况它是Kent

现在比较火的IDE是JIDE，但是我一直在使用eclipse。对eclipse比较熟悉了，也有了感情了。这里就以eclipse为例，来整理下eclipse中junit插件的使用。添加junit包到自己的工程中：这里eclipse有自带junit的包，可以直接拿来使用的。但是实际项目中我们一般用的maven，所以为了统一还是和大家使用同样version的junit好点。在这里

今天开始junit使用系列，第一篇梳理junit3X系列，先贴下代码来体验下。测试源代码如下：package test.junit38test;/** * @创建作者： LinkinPark * @创建时间： 2016年1月26日 * @功能描述： 这里写一个算法类，实现加减乘除 */public class Linkin{ public int add(int a

我们平时编写自己的测试类，如果没有断言，那么就没写测试的必要了。JUnit框架用一组assert方法封装了最常见的测试任务。这些assert方法可以极大地简化单元测试的编写。Assert类包含了一组静态的测试方法，用于验证期望值expected和实际值actual逻辑比对是否正确，即测试失败，标志为未通过测试。如果期望值和实际值比对失败，Assert类就会抛出一个Assertion

OK，现在我们正式开始junit4系列的整理。前面的junit38作为4的补充知道就好了，实际编码中我们以4为主。这里先来一把junit的初体验，同时也让我们来一步一步的了解下TDD的好处。ORM大家肯定熟悉的不能再熟悉了，大Java面向对象编码，但是数据库存的是表结构，所以我们不可避免的就要来做ORM映射。其中关键的一步就是将Java对象映射成数据库中的表，将一个Java对象的属性映射成数据

借助Java 5 注释，JUnit 4 比从前更轻（量级），也更加灵活。JUnit 4 放弃了严格的命名规范和继承层次，转向了一些令人激动的新功能。下面是一份关于 JUnit 4 新功能的快速列表：l  参数测试l  异常测试l  超时测试l  灵活固件l  忽略测试的简单方法l  对测试进行逻辑分组的新方法。让我们来一个一个整理。兵马未动，注解先行。注解先行之前，

JUnit 提供注解 org.junit.Ignore 用于暂时忽略某个测试方法或者说整个类。因为有时候由于测试环境受限，并不能保证每一个测试方法都能正确运行。1，方法级别上使用@ignore来注释我们的测试方法，结果就是该方法在测试执行时会被跳过。测试结束后，还可以获取详细的统计信息，不仅包括了测试成功和测试失败的次数，也包括了被忽略的测试数目。例如下面的代码便表示由于没有了数据库链

在前面的junit4初体验中我就说过，junit参数化测试是一只小怪兽，只逼编码痛点，现在我们这里来整理一下。看过我前面的那篇初体验的就会发现一个问题，我们的测试代码大量的重复了。在这里先贴出原来的那2篇代码：测试源码：package test.junit4test;import java.util.regex.Matcher;import java.util.regex.P

命令模式的意图　　将一个请求封装成一个对象，从而使你可以用不同的请求对客户进行参数化；　　对请求排队或记录请求日志，以及支持可撤销的操作；　　命令模式告诉我们可以为一个操作生成一个对象并给出它的一个执行方法。命令模式的构成　　1.客户角色：　　创建一个具体命令对象，并确定其接受者。　　2.命令角色：　　声明一个给所有具体命令类的抽象接口。

适配器（Adapter）模式　　在软件系统中，由于环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。那么如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？　　这就要利用Adapter模式。Adapter模式意图　　1，将一个类的接口转换成客户希望的另一个接口。　　

关于junit测试的延伸，这里有类概念级别的测试，继承类的测试，接口的测试，抽象类的测试，关于这些类级别的测试，这里我就不做多的赘述了。关于上面的几个测试就是说，我们不应该单纯的去测试类中的一些方法，而且要测试类的状态，也就是那些属性状态。我个人觉得没太大必要，实际编码测试中我们直接测试方法的正确性就够了，一个类的状态是通过方法来改变的，所以正确的初始化后基本不会有太大问题。这里我要整理的

在实际编码测试中，我们有的时候需要对一个方法进行多次测试，那么怎么办呢？这个问题和测试套件解决的方案一样，我们总不能不停的去右键run as，那怎么办呢？还好伟大的junit帮我们想到了。OK，现在我们开始来写一个例子：测试源码：package org.linkinpark.junit.testjunit;/** * @创建作者： LinkinPark * @创建时间： 201

前面我整理了junit38系列的源码，那junit4X核心代码也基本类似。这里我先转载一些关于junit4X源码解析的好文章。感谢原作者的分享。原文地址：http://www.blogjava.net/DLevin/archive/2012/05/11/377950.html。初次用文字的方式记录读源码的过程，不知道怎么写，感觉有点贴代码的嫌疑。不过中间还是加入了一些自己的理解和心得，希望以后

原文出处：http://www.blogjava.net/DLevin/archive/2012/05/11/377954.html。感谢作者的无私分享。初次用文字的方式记录读源码的过程，不知道怎么写，感觉有点贴代码的嫌疑。不过中间还是加入了一些自己的理解和心得，希望以后能够慢慢的改进，感兴趣的童鞋凑合着看吧，感觉JUnit这个框架还是值得看的，里面有许多不错的设计思想在，更何况它是K

原文出处：http://www.blogjava.net/DLevin/archive/2012/05/12/377955.html。感谢作者的无私分享。初次用文字的方式记录读源码的过程，不知道怎么写，感觉有点贴代码的嫌疑。不过中间还是加入了一些自己的理解和心得，希望以后能够慢慢的改进，感兴趣的童鞋凑合着看吧，感觉JUnit这个框架还是值得看的，里面有许多不错的设计思想在，更何况它是K

Composite，英语翻译下，复合，组合。组合模式有时候又叫做部分-整体模式，它使我们在树形结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素，从而使得客户与复杂元素的内部结构解耦。将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得用户对单个对象和组合对象的使用具有一致性。组合模式（Composite）的组成