L19.3 测试驱动开发和重构和其他内容简介

系统分析与设计

第21章测试驱动开发和重构

目标结合学习案例，介绍测试驱动开发和重构这两种重要的开发实践极限编程(XP)所提倡的重要测试实践是:首先编写测试。它还提倡不断地重构代码以改进质量，包括降低冗余、提高清晰度等。现代工具也都支持这两种实践。21.1测试驱动开发(TDD)

1.什么是测试驱动开发

测试驱动开发是迭代和敏捷XP方法提倡的优秀实践，也适用于UP，该实践也称测试优先开发。TDD涵盖单元测试即对构件个体进行测试，这里着重介绍对单个类进行单元测试的应用。在TDD的OO单元测试中，要在测试类之前编写测试代码，并且开发者要为几乎所有的产品代码编写单元测试代码。其基本方法是先编写一小段测试代码，然后编写一小段产品代码保证其通过测试，依此类推。2.测试驱动开发的优点

1)事先编写单元测试以防止人为地忽略单元测试;2)令人鼓舞的测试不仅可以使程序员获得满足感,而且可使程序员意识到编程的挑战性;3)坚持测试优先的原则以避免程序员试图跳过测试或随心所欲的测试;4)有助于改善接口和行为的设计细节.因为测试是从实际需求出发的,它能指导开发者如何考虑诸如方法名称、返回值、参数和行为等细节。5）累积的单元测试代码能够提供有意义的正确性验证，而且能够十分简便地自动运行。当测试库累积到一定规模时，这种投入会产生重要回报。

6）当测试库具备一定规模时，可以测试修改可能导致的问题。当开发者准备更改现有代码时，可以运行的单元测试集会发现你的更改是否会导致错误。3.单元测试框架和编写单元测试的步骤最为流行的单元测试框架是xUnit家族，参见,对于Java,其常用版本是JUnit。也有针对.NET的Nunit等等。大多数JavaIDE都集成了JUnit，例如Eclipse。遵守如下步骤完成每个测试方法：

1）创建被测试固件

2）让它完成你要测试的操作

3）评估结果是否为期望值4.示例假设使用JUnit和TDD来创建Sale类。在编写Sale类之前，我们要在SaleTest类中按照如下步骤编写单元测试方法：

1）创建Sale---被测试的事物，也称测试固件（fixture）。

2）使用makeLineItem方法（我们想要测试的public方法）为其增加一些商品条目。

3）请求总计金额，并且使用assertTrue方法验证是否为期望值。注意：

1）我们并没有先为Sale编写所有的单元测试，而只编写了一个测试方法，等到在Sale类中实现该方法并确保通过了测试，然后再反复这一过程，直到结束。

2）要使用JUnit，你必须创建并扩展JUnit的TestCase类的测试类，这样测试类才可以继承各种单元测试的行为。

3）在JUnit中，你要为想要测试的每个方法创建单独的测试方法。但不必为诸如get和Set方法编写测试方法（通常会自动生成）。例如：

publicclassSaleTestextedsTestCase{//…//测试Sale.makeLineItem方法

publicvoidtestMakeLineItem(){//步骤1:创建测试固件,约定命名为‘fixture’,//通常定义为实例字段而非局部变量.Salefixture=newSale();//设置辅助测试的对象

Moneytotal=newMoney(7.5);Moneyprice=newMoney(2.5);ItemIDid=newItemID(1);ProductDescriptiondesc=newProductDescription(id,price,“product1”);//步骤2：执行测试方法makeLineItem

fixture.makeLineItem(desc,1);

fixture.makeLineItem(desc,2);//步骤3：评估结果，验证结果是否为7.5，

//对于复杂的评估可能有很多assertTrue语句

assertTrue(sale.getTotal().equals(total));}}

只有在编写完testMakeLineItem()测试方法之后,才开始编写Sale.makeLineItem方法,并且要通过这一测试。所以才叫测试驱动开发或测试优先开发。5.IDE对TDD和xUnit的支持大多数IDE都会对xUnit提供支持，例如，Eclipse支持JUnit。其中的JUnit包括可视化的提示，即当测试通过后，将会显示绿条。由此产生了TDD的一句俗语：保持状态条为绿色就是保持代码的纯净见下图：21.2重构

1.什么是重构?

重构是重写或重新构建已有代码的结构化和规律性方法，但不会改变已有代码的外在行为。而是采用一系列少量转换的步骤，并且每一步都结合了重新执行的测试。不断地重构代码也是XP的一个实践，该实践也适用于所有迭代方法，包括UP。重构的本质是一次实行一小步保留行为的转化。每次转化都称为重构。每次转化之后要重新执行单元测试，以保证重构不会导致错误。2.重构的活动和目标*去除冗余代码*改善清晰度*使过长的方法变得较短*去除硬编码的字面常量*更多…

进行良好重构的代码应该是简短、紧凑、清晰的且没有冗余。不具备这些品质的代码是坏味代码（codesmell）。坏味代码不见的就是错误代码。恶臭代码（codestench）是真正要清理的垃圾代码。

重构正是对坏味代码进行矫正。与模式类似，重构也有名称，大约有100多个已命名的重构。例如：*提炼方法（ExtractMethod）:将较长的方法转化为较短的方法。*提炼常量（ExtractConstant）:使用常量变量替换字面常量。*引入解释变量…*使用工厂方法代替构造器调用…

等等。

3.示例

1)描述提炼方法示例该示例中所列的Player类中的takeTurn方法,其中在代码的开始部分完成了抛掷子和在循环中计算总点数的操作。这段代码本身是独立和内聚的行为单元，我们可以将这些代码提炼为私有的帮助者方法rollDice，以使takeTurn变得简短、清晰，并能更好地支持高内聚。注意takeTurn方法中需要rollTotal的值，因此rollDice必须返回rollTotal。重构前的takeTurn方法publicclassPlayer{

privatePiecepiece; privateBoardboard; privateDie[]dice; //…publicvoidtakeTurn(){//rolldice introllTotal=0; for(inti=0;i<dice.length;i++) { dice[i].roll(); rollTotal+=dice[i].getFaceValue(); }SquarenewLoc=board.getSquare(piece.getLocation(),rollTotal); piece.setLocation(newLoc);}}//endofclass提炼方法重构后的代码publicclassPlayer{

privatePiecepiece; privateBoardboard; privateDie[]dice; //…publicvoidtakeTurn(){//therefactoredhelpermethod introllTotal=rollDice();SquarenewLoc=board.getSquare(piece.getLocation(),rollTotal); piece.setLocation(newLoc);}privateintrollDice(){

introllTotal=0; for(inti=0;i<dice.length;i++) {

dice[i].roll(); rollTotal+=dice[i].getFaceValue(); } returnrollTotal;}}//endofclass2）引入解释变量的示例引入解释变量之前的代码：//goodmethodname,butthelogicofthebodyisnotclearbooleanisLeapYear(intyear){ return (((year%400)==0)|| (((year%4)==0)&&((year%100)!=0)));}引入解释变量之后的代码：//that’sbetter!booleanisLeapYear(intyear){

booleanisFourthYear=((year%4)==0);booleanisHundrethYear=((year%100)==0);booleanis4HundrethYear=((year%400)==0);return(is4HundrethYear||(isFourthYear&&！isHundrethYear));}4.IDE对重构的支持大部分常用的IDE都支持自动重构。如图,其中rollDice方法是自动生成的。重构之前的IDE重构之后的IDE第22章UML工具与UML蓝图

目标简要了解UML的使用方式22.1UML应用的三种方式

1.UML作为草图

2.UML作为蓝图:适用与代码和图形的生成。利用工具，使用相对详细的图形来指导代码的生成。生成代码以后，通常还需要开发人员添加大量细节。还可以从代码生成图形，用来可视化代码库。

3.UML作为编程语言:UML形式的软件系统的完整的可执行规格说明。可执行代码会被自动生成，或由虚拟机直接解释。大部分UML工具支持第二种方法。22.2前向、逆向和双向工程在CASE工具的领域中，前向工程是从图形生成代码，逆向工程是从代码生成图形。而双向工程是则支持双向生成。所有UML工具都声称支持这些特性，但大部分只能实现其中部分特性。因为多数工具只能完成静态模型：可以从代码生成类图，但无法生成交互图，或者可以从类图生成类的基本定义，但无法从交互图生成方法体。

第四部分

细化迭代2:处理税金和计价规则在细化迭代2中应用更多模式进行设计第23章引言1.我们已经学习了什么?

在第一次迭代中我们已经学习了基本的面向对象的系统分析方法和对象设计技术。2.第二次迭代中的学习重点是什么？进一步学习对象设计技术，并学习使用更多的设计模式来创建稳固的设计，学习应用UML使模型可视化。3.在案例开发的迭代1中我们完成了什么?1）所有的阶段性软件都已充分地测试,包括单元测试、验收测试、负载测试、可用性测试。

2）客户定期地参与了对已完成部分的评估。开发人员已获得对调整和澄清需求的反馈，客户也认可了系统进一步完善的需求。

3）已经对已完成的系统进行了完整的集成和固化，使其成为基线化的内部版本。4.从迭代1到迭代2的转移过程中有许多事情要做。为突出重点，不详细讨论。这些事情包括：*迭代计划会议*使用UML工具从第一次迭代的源码中导出图形，并挂在墙上，作为沟通和新一轮迭代的起点。*对UI的分析和设计，以及对数据库的建模和实现也在进行中。*举行了新一轮需求讨论会。5.迭代2的需求和重点在迭代2中我们将忽略需求分析和领域分析,把重点放在对象设计和模式应用上。在POS应用的第二次迭代中，关注处理销售用例场景的如下需求：*支持第三方外部服务的变化，如处理支付和计算税金等。*支持复杂的定价规则。*支持窗口刷新。这些需求在初始阶段就已在用例和补充规格说明中提出了。第24章快速地更新分析目标快速地突出显示一些分析制品的变更。1.用例需要更新吗？就POS应用的案例来说，第二次迭代仍然是基于原有用例，因为在第一次迭代中我们只处理了主成功场景，且只处理现金支付。在第二次迭代中要处理税金计算和计价规则问题。原有用例已反映这些需求，不必更新。

2.SSD需要更新吗?

本次迭代要处理对具有不同接口的第三方外部系统（如税金计算器）的支持，POS应用系统将与这些外部系统进行通信。增加边界外的参与者，系统事件会发生变化，一些系统操作的要求也会变化。所以，SSD必须更新。下图示出了对原有SSD的更新：

1）参与者的更新

2）系统操作流的更新图中包括在下一次迭代要处理的信用卡支付需求。描述信用卡支付的SSD场景makeCreditPayment(credNum,expiryDate)reply=requestApproval(request)postReceivable(receivable)«actor»:CreditAuthorizationService«actor»:AccountsenterItem(itemID,quantity):NextGenPOS