Junit《一》
1. 使用Junit的最佳实践:
1)新建一个名为test的source folder,用于存放测试类源代码
2)目标类与测试类应该位于同一个包下面,这样测试类中就不必知道源代码所在的包,因为他们位于同一包下面
3)测试类的命名规则:假如目标类是Calculator,那么测试类应该命名为TestCalculator或者是CalculatorTest
2.Junit的口号:keep the bar greeen to keep the code clean.(保持bar绿色保持代码整洁。)
张龙名言:没有反射,很多框架就不存在了。(No Reflection,No most frameworks)。
3.Junit:单元测试不是为了您是对的,而是证明您没有错误
4.测试用例(Test Case ) 是单元测试的一个很重要的方面。
5.单元测试主要是用来判断程序的执行结果与自己期望的结果是否一致。
6. 在junit 3.8中,测试方法需要满足如下原则:
1).public 的
2).void 的
3).无方法参数
4).方法名必须以test开头
7. TestCase 之间一定要保持完全独立性,不允许出现任务的依赖关系。
8. 我们不能依赖于测试方法的执行顺序。
9. DRY(Don't Repeat yourself) (不要重复你自己)
10. 关于setUp与tearDown方法的执行顺序:
1)setUp
2)testAdd
3)tearDown
11.测试之前是什么状态,测试执行完毕后就应该是什么状态,而不应该由于测试执行的原因导致状态发生了变化。
1) 修改方法的访问修饰符,将privae修改为default或public(但不推荐采取这种方式)
2)使用反射在测试类中调用目标类的私有方法(推荐)
2.TestSuite(测试套件):可以将多个测试组合到一起,同时执行多个测试
3.RepeatedTest 方法的重复执行
4.Junit4 全面引入了Annotation来执行我们编写的测试。
5.Junit4 并不需要求测试类继承TestCase父类
6.在一个测试类中,所有被@Test注解所修饰的public,void方法都是testcase,可以被Junit所执行
7.虽然Junit4并不要求测试方法名以test开头,但是我们最好还是按照Junit3.8要求,以test作为测试方法名的开头。
8.在junit4中,通过@Before注解实现与Junit3.8中的setup方法同样的功能,通过@After注解实现与Junit3.8中的tearDown方法同样的功能。
9.在JUnit4中,可以使用@BeforeClass与@AfterClass注解修饰一个public static void no-arg的方法,这样被@Before注解所修饰的方法会在所有测试方法执行之前执行;
被@After注解所修饰的方法会在所有测试方法执行之后执行。
10.@Ignore注解可用于修饰测试类与测试方法,当修饰测类时,表示忽略掉类中的所有测试方法;当修饰测试方法时,表示忽略掉了该测试方法。
11.参数化测试(Parameters):当一个测试类使用参数化运行器运行时,需要在类的声明处加上@RunWith(Paramterized.class)注解,
表示该类将不使用JUnit内建的运行器运行,而使用参数化运行器运行;在参数化运行类中提供参数的方法上要使用@Parameters注解来修饰,
同时在测试类的构造方法中为各个参数赋值(构造方法是由Junit调用的),最后编写测试类,他会根据参数的数组来运行测试多少次。
12.在Junit4中,如果想要同时运行几个测试,需要使用两个注解:@RunWith(Sute.class)以及@Suite.SuiteClasses(),
通过这两个注解分别制定使用Suite运行器来运行测试,以及制定了运行那些测试类,其中@SuiteClasses中可以继续指定Suite,
这样Junit会再去寻找里面的测试类,一直找到能够执行的TestCase并执行之。
13.模版方法模式(Template Method)
定义一个操作中的算法骨架,而将一些步骤延伸到子类中去,使得子类可以不改变一个算法的结构,即可重新定义改算法的某些特定步骤。
这里需要复用的是算法的结构,也就是步骤,而步骤的实现可以在子类中完成。
1)一次性实现一个算法的不变部分,并且将可变的行为留给子类来完成。
2)各子类公共的行为应该被提取出来并集中到一个公共父类中以避免代码的重复。首先识别现有代码的不同之处,并且把不同部分分离为
新的操作,最后,用一个调用这些新的操作的模板方法来替换这些不同的代码。
3)控制子类的扩展。
模板方法模式的组成
--父类角色:提供模板。
--子类角色:为模板提供实现。
14.适配器(Adapter)模式
在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的。
那么如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口?这就是本文所要说的Adapter模式。
意图
将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
适配器(Adapter)模式的构成
*目标抽象角色(Target)
--定义客户要用的特定领域的接口。
*适配器(Adapter)
--调用另一个接口,作为一个转换器
*适配器(Adaptee)
--定义一个接口,Adapter需要介入
*客户端(Client)
--协同对象符合Adapter适配器
适配器的分类
有两种类型的适配器模式
--类适配器(采取继承的方式)
--对象适配器(采取对象组合的方式)推荐
15.Junit在TestCase类中应用了适配器(Adapter)模式:
public void runBare() throws Throwable{
setUp();
try{
runTest();
}
finally{
tearDown();
}
}
在runBare方法中,通过runTest方法将我们自己编写的testXXX方法进行了适配,使得JUnit可以执行我们
自己编写的TestCase,runTest方法的实现如下:
------就是通过反射进行的方式适配调用。
在runTest方法中,首先获得我们自己编写的testXXX方法所对应的Method对象(不带参数),然后检查该
Method所对应的方法是否是public的,如果是则调用Method对象的invoke方法来执行我们自己编写的testXXX方法。
1.适配器模式主要分为三种:
1)基于类的继承方式
2)基于对象组合方式
3)缺省的适配器模式(AWT,Swing事件模型所采用的模式)
2.命令(Command)模式
Command(命令)模式则能够比较好地满足需求。将一个请求封装成一个对象,从而使你可用不同的请求对客户进行参数化;
对请求进行排队或记录请求日志..."Command模式告诉我们可以为一个操作生成一个对象并给出它的一个"execute(执行)"方法。
意图:
将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可成效的操作。
命令(Command)模式
下面来考虑经过使用Command模式后给系统的架构带来哪些效果:
Command模式将实现请求的一方(TestCase开发)和调用一方(JUnit)进行解耦
Command模式使新的TestCase很容易加入,无需改变已有的类,只需继承TestCase类,这样方便了测试人员。
Command模式可以将多个TestCase进行组合成一个复合命令,你将看到TestSuit就是他的复合命令,当然它使用了Composite模式
Command模式容易把请求的TestCase组合成请求队列,这样使接受请求的一方(Junit Fromwork),容易决定是否执行请求,
一旦发现测试用例失败或者错误可以立刻停止进行报告
命令模式的构成
1 客户角色:创建一个具体命令对象,并确定其接受者
2.命令角色:声明一个给所有具体命令的抽象接口。这是一个抽象角色,通常由一个接口或抽象类实现。
3.具体命令角色:定一个接收这和行为之间的弱耦合,实现execute方法,负责调用接收者的相应操作
4.请求者角色:负责调用命令对象执行请求。
5.接收者角色:负责具体实施和执行一个请求。
3.我们学习过的设计模式:
1)单例模式(singleton)
2)策略模式(Strategy)
3)代理模式(static proxy,daynamic proxy)
4)观察者模式(Observer)
5)装饰模式(Decorator)
6)工厂方法模式(Factory Method)
7)模版方法模式(Template method)
8)适配器模式(Adapter)
9)命令模式(Command)
10)组合模式(Compsite)
4.组合模式(Composite):
Component(抽象构件接口)
-为组合的对象声明接口
-在某些情况下实现从此接口派生出来的所有类共有的默认行为
-定义一个接口可以访问及管理他的多个部件
Leaf(叶部件)
-在组合中表示叶节点对象,叶节点没有子节点
-定义组合中接口对象的行为
Composite(组合类)
-定义有子节点(子部件)的部件的行为
-存储子节点(子部件)
-在Component接口中实现与子部件相关的操作
Client(客户端)
-通过Component接口控制组合部件的对象
4.组合模式(Composite):组合模式有两种实现方式:
1)将管理子元素的方法定义在composite类中。
2)将管理子元素的方法定义在Component接口中,这样Leaf类就需要对这些方法空实现。
5.对于测试类来说,如果一个测试类中有5个测试方法,那么JUnit就会创建5个测试类的对象,
每一个对象只会调用一个测试方法(为了符合命令模式的要求),在添加方法之前,需要首先判断
测试方法是否是public,void,no-arg,no-return这些条件如果满足则添加到集合当中准备作为测试方法去执行。
1. 使用Junit的最佳实践:
1)新建一个名为test的source folder,用于存放测试类源代码
2)目标类与测试类应该位于同一个包下面,这样测试类中就不必知道源代码所在的包,因为他们位于同一包下面
3)测试类的命名规则:假如目标类是Calculator,那么测试类应该命名为TestCalculator或者是CalculatorTest
2.Junit的口号:keep the bar greeen to keep the code clean.(保持bar绿色保持代码整洁。)
张龙名言:没有反射,很多框架就不存在了。(No Reflection,No most frameworks)。
3.Junit:单元测试不是为了您是对的,而是证明您没有错误
4.测试用例(Test Case ) 是单元测试的一个很重要的方面。
5.单元测试主要是用来判断程序的执行结果与自己期望的结果是否一致。
6. 在junit 3.8中,测试方法需要满足如下原则:
1).public 的
2).void 的
3).无方法参数
4).方法名必须以test开头
7. TestCase 之间一定要保持完全独立性,不允许出现任务的依赖关系。
8. 我们不能依赖于测试方法的执行顺序。
9. DRY(Don't Repeat yourself) (不要重复你自己)
10. 关于setUp与tearDown方法的执行顺序:
1)setUp
2)testAdd
3)tearDown
11.测试之前是什么状态,测试执行完毕后就应该是什么状态,而不应该由于测试执行的原因导致状态发生了变化。
Junit《二》
1) 修改方法的访问修饰符,将privae修改为default或public(但不推荐采取这种方式)
2)使用反射在测试类中调用目标类的私有方法(推荐)
2.TestSuite(测试套件):可以将多个测试组合到一起,同时执行多个测试
3.RepeatedTest 方法的重复执行
4.Junit4 全面引入了Annotation来执行我们编写的测试。
5.Junit4 并不需要求测试类继承TestCase父类
6.在一个测试类中,所有被@Test注解所修饰的public,void方法都是testcase,可以被Junit所执行
7.虽然Junit4并不要求测试方法名以test开头,但是我们最好还是按照Junit3.8要求,以test作为测试方法名的开头。
8.在junit4中,通过@Before注解实现与Junit3.8中的setup方法同样的功能,通过@After注解实现与Junit3.8中的tearDown方法同样的功能。
9.在JUnit4中,可以使用@BeforeClass与@AfterClass注解修饰一个public static void no-arg的方法,这样被@Before注解所修饰的方法会在所有测试方法执行之前执行;
被@After注解所修饰的方法会在所有测试方法执行之后执行。
10.@Ignore注解可用于修饰测试类与测试方法,当修饰测类时,表示忽略掉类中的所有测试方法;当修饰测试方法时,表示忽略掉了该测试方法。
11.参数化测试(Parameters):当一个测试类使用参数化运行器运行时,需要在类的声明处加上@RunWith(Paramterized.class)注解,
表示该类将不使用JUnit内建的运行器运行,而使用参数化运行器运行;在参数化运行类中提供参数的方法上要使用@Parameters注解来修饰,
同时在测试类的构造方法中为各个参数赋值(构造方法是由Junit调用的),最后编写测试类,他会根据参数的数组来运行测试多少次。
12.在Junit4中,如果想要同时运行几个测试,需要使用两个注解:@RunWith(Sute.class)以及@Suite.SuiteClasses(),
通过这两个注解分别制定使用Suite运行器来运行测试,以及制定了运行那些测试类,其中@SuiteClasses中可以继续指定Suite,
这样Junit会再去寻找里面的测试类,一直找到能够执行的TestCase并执行之。
13.模版方法模式(Template Method)
定义一个操作中的算法骨架,而将一些步骤延伸到子类中去,使得子类可以不改变一个算法的结构,即可重新定义改算法的某些特定步骤。
这里需要复用的是算法的结构,也就是步骤,而步骤的实现可以在子类中完成。
1)一次性实现一个算法的不变部分,并且将可变的行为留给子类来完成。
2)各子类公共的行为应该被提取出来并集中到一个公共父类中以避免代码的重复。首先识别现有代码的不同之处,并且把不同部分分离为
新的操作,最后,用一个调用这些新的操作的模板方法来替换这些不同的代码。
3)控制子类的扩展。
模板方法模式的组成
--父类角色:提供模板。
--子类角色:为模板提供实现。
14.适配器(Adapter)模式
在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的。
那么如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口?这就是本文所要说的Adapter模式。
意图
将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
适配器(Adapter)模式的构成
*目标抽象角色(Target)
--定义客户要用的特定领域的接口。
*适配器(Adapter)
--调用另一个接口,作为一个转换器
*适配器(Adaptee)
--定义一个接口,Adapter需要介入
*客户端(Client)
--协同对象符合Adapter适配器
适配器的分类
有两种类型的适配器模式
--类适配器(采取继承的方式)
--对象适配器(采取对象组合的方式)推荐
15.Junit在TestCase类中应用了适配器(Adapter)模式:
public void runBare() throws Throwable{
setUp();
try{
runTest();
}
finally{
tearDown();
}
}
在runBare方法中,通过runTest方法将我们自己编写的testXXX方法进行了适配,使得JUnit可以执行我们
自己编写的TestCase,runTest方法的实现如下:
------就是通过反射进行的方式适配调用。
在runTest方法中,首先获得我们自己编写的testXXX方法所对应的Method对象(不带参数),然后检查该
Method所对应的方法是否是public的,如果是则调用Method对象的invoke方法来执行我们自己编写的testXXX方法。
Junit《三》
1.适配器模式主要分为三种:
1)基于类的继承方式
2)基于对象组合方式
3)缺省的适配器模式(AWT,Swing事件模型所采用的模式)
2.命令(Command)模式
Command(命令)模式则能够比较好地满足需求。将一个请求封装成一个对象,从而使你可用不同的请求对客户进行参数化;
对请求进行排队或记录请求日志..."Command模式告诉我们可以为一个操作生成一个对象并给出它的一个"execute(执行)"方法。
意图:
将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可成效的操作。
命令(Command)模式
下面来考虑经过使用Command模式后给系统的架构带来哪些效果:
Command模式将实现请求的一方(TestCase开发)和调用一方(JUnit)进行解耦
Command模式使新的TestCase很容易加入,无需改变已有的类,只需继承TestCase类,这样方便了测试人员。
Command模式可以将多个TestCase进行组合成一个复合命令,你将看到TestSuit就是他的复合命令,当然它使用了Composite模式
Command模式容易把请求的TestCase组合成请求队列,这样使接受请求的一方(Junit Fromwork),容易决定是否执行请求,
一旦发现测试用例失败或者错误可以立刻停止进行报告
命令模式的构成
1 客户角色:创建一个具体命令对象,并确定其接受者
2.命令角色:声明一个给所有具体命令的抽象接口。这是一个抽象角色,通常由一个接口或抽象类实现。
3.具体命令角色:定一个接收这和行为之间的弱耦合,实现execute方法,负责调用接收者的相应操作
4.请求者角色:负责调用命令对象执行请求。
5.接收者角色:负责具体实施和执行一个请求。
3.我们学习过的设计模式:
1)单例模式(singleton)
2)策略模式(Strategy)
3)代理模式(static proxy,daynamic proxy)
4)观察者模式(Observer)
5)装饰模式(Decorator)
6)工厂方法模式(Factory Method)
7)模版方法模式(Template method)
8)适配器模式(Adapter)
9)命令模式(Command)
10)组合模式(Compsite)
4.组合模式(Composite):
Component(抽象构件接口)
-为组合的对象声明接口
-在某些情况下实现从此接口派生出来的所有类共有的默认行为
-定义一个接口可以访问及管理他的多个部件
Leaf(叶部件)
-在组合中表示叶节点对象,叶节点没有子节点
-定义组合中接口对象的行为
Composite(组合类)
-定义有子节点(子部件)的部件的行为
-存储子节点(子部件)
-在Component接口中实现与子部件相关的操作
Client(客户端)
-通过Component接口控制组合部件的对象
4.组合模式(Composite):组合模式有两种实现方式:
1)将管理子元素的方法定义在composite类中。
2)将管理子元素的方法定义在Component接口中,这样Leaf类就需要对这些方法空实现。
5.对于测试类来说,如果一个测试类中有5个测试方法,那么JUnit就会创建5个测试类的对象,
每一个对象只会调用一个测试方法(为了符合命令模式的要求),在添加方法之前,需要首先判断
测试方法是否是public,void,no-arg,no-return这些条件如果满足则添加到集合当中准备作为测试方法去执行。