1700456478
private int price=6000；
1700456479
1700456480
private String author=“路遥”；
1700456481
1700456482
private IBook novelBook=new NovelBook（name,price,author）；
1700456483
1700456484
//测试getPrice方法
1700456485
1700456486
public void testGetPrice（）{
1700456487
1700456488
//原价销售，根据输入和输出的值是否相等进行断言
1700456489
1700456490
super.assertEquals（this.price,this.novelBook.getPrice（））；
1700456491
1700456492
}
1700456493
1700456494
}
1700456495
1700456496
单元测试通过，显示绿条。在单元测试中，有一句非常有名的话，叫做”Keep the bar green to keep the code clean”，即保持绿条有利于代码整洁，这是什么意思呢？绿条就是Junit运行的两种结果中的一种：要么是红条，单元测试失败；要么是绿条，单元测试通过。一个方法的测试方法一般不少于3种，为什么呢？首先是正常的业务逻辑要保证测试到，其次是边界条件要测试到，然后是异常要测试到，比较重要的方法的测试方法甚至有十多种，而且单元测试是对类的测试，类中的方法耦合是允许的，在这样的条件下，如果再想着通过修改一个方法或多个方法代码来完成变化，基本上就是痴人说梦，该类的所有测试方法都要重构，想象一下你在一堆你并不熟悉的代码中进行重构时的感觉吧！
1700456497
1700456498
在书店售书的例子中，增加了一个打折销售的需求，如果我们直接修改getPrice方法来实现业务需求的变化，那就要修改单元测试类。想想看，我们举的这个例子是非常简单的，如果是一个复杂的逻辑，你的测试类就要修改得面目全非。还有，在实际的项目中，一个类一般只有一个测试类，其中可以有很多的测试方法，在一堆本来就很复杂的断言中进行大量修改，难免会出现测试遗漏情况，这是项目经理很难容忍的事情。
1700456499
1700456500
所以，我们需要通过扩展来实现业务逻辑的变化，而不是修改。上面的例子中通过增加一个子类OffNovelBook来完成了业务需求的变化，这对测试有什么好处呢？我们重新生成一个测试文件OffNovelBookTest，然后对getPrice进行测试，单元测试是孤立测试，只要保证我提供的方法正确就成了，其他的我不管，OffNovelBookTest如代码清单6-7所示。
1700456501
1700456502
代码清单6-7 打折销售的小说类单元测试
1700456503
1700456504
public class OffNovelBookTest extends TestCase{
1700456505
1700456506
private IBook below40NovelBook=new OffNovelBook（“平凡的世界”，3000，“路遥”）；
1700456507
1700456508
private IBook above40NovelBook=new OffNovelBook（“平凡的世界”，6000，“路遥”）；
1700456509
1700456510
//测试低于40元的数据是否是打8折
1700456511
1700456512
public void testGetPriceBelow40（）{
1700456513
1700456514
super.assertEquals（2400，this.below40NovelBook.getPrice（））；
1700456515
1700456516
}
1700456517
1700456518
//测试大于40的书籍是否是打9折
1700456519
1700456520
public void testGetPriceAbove40（）{
1700456521
1700456522
super.assertEquals（5400，this.above40NovelBook.getPrice（））；
1700456523
1700456524
}
1700456525
1700456526
}
1700456527
[
上一页 ]
[ :1.700456478e+09 ]
[
下一页 ]