L19.3 測試驅動開發(fā)和重構和其他內容簡介

系統(tǒng)分析與設計

第21章測試驅動開發(fā)和重構

目標結合學習案例，介紹測試驅動開發(fā)和重構這兩種重要的開發(fā)實踐極限編程(XP)所提倡的重要測試實踐是:首先編寫測試。它還提倡不斷地重構代碼以改進質量，包括降低冗余、提高清晰度等?，F(xiàn)代工具也都支持這兩種實踐。21.1測試驅動開發(fā)(TDD)

1.什么是測試驅動開發(fā)

測試驅動開發(fā)是迭代和敏捷XP方法提倡的優(yōu)秀實踐，也適用于UP，該實踐也稱測試優(yōu)先開發(fā)。TDD涵蓋單元測試即對構件個體進行測試，這里著重介紹對單個類進行單元測試的應用。在TDD的OO單元測試中，要在測試類之前編寫測試代碼，并且開發(fā)者要為幾乎所有的產品代碼編寫單元測試代碼。其基本方法是先編寫一小段測試代碼，然后編寫一小段產品代碼保證其通過測試，依此類推。2.測試驅動開發(fā)的優(yōu)點

1)事先編寫單元測試以防止人為地忽略單元測試;2)令人鼓舞的測試不僅可以使程序員獲得滿足感,而且可使程序員意識到編程的挑戰(zhàn)性;3)堅持測試優(yōu)先的原則以避免程序員試圖跳過測試或隨心所欲的測試;4)有助于改善接口和行為的設計細節(jié).因為測試是從實際需求出發(fā)的,它能指導開發(fā)者如何考慮諸如方法名稱、返回值、參數(shù)和行為等細節(jié)。5）累積的單元測試代碼能夠提供有意義的正確性驗證，而且能夠十分簡便地自動運行。當測試庫累積到一定規(guī)模時，這種投入會產生重要回報。

6）當測試庫具備一定規(guī)模時，可以測試修改可能導致的問題。當開發(fā)者準備更改現(xiàn)有代碼時，可以運行的單元測試集會發(fā)現(xiàn)你的更改是否會導致錯誤。3.單元測試框架和編寫單元測試的步驟最為流行的單元測試框架是xUnit家族，參見,對于Java,其常用版本是JUnit。也有針對.NET的Nunit等等。大多數(shù)JavaIDE都集成了JUnit，例如Eclipse。遵守如下步驟完成每個測試方法：

1）創(chuàng)建被測試固件

2）讓它完成你要測試的操作

3）評估結果是否為期望值4.示例假設使用JUnit和TDD來創(chuàng)建Sale類。在編寫Sale類之前，我們要在SaleTest類中按照如下步驟編寫單元測試方法：

1）創(chuàng)建Sale---被測試的事物，也稱測試固件（fixture）。

2）使用makeLineItem方法（我們想要測試的public方法）為其增加一些商品條目。

3）請求總計金額，并且使用assertTrue方法驗證是否為期望值。注意：

1）我們并沒有先為Sale編寫所有的單元測試，而只編寫了一個測試方法，等到在Sale類中實現(xiàn)該方法并確保通過了測試，然后再反復這一過程，直到結束。

2）要使用JUnit，你必須創(chuàng)建并擴展JUnit的TestCase類的測試類，這樣測試類才可以繼承各種單元測試的行為。

3）在JUnit中，你要為想要測試的每個方法創(chuàng)建單獨的測試方法。但不必為諸如get和Set方法編寫測試方法（通常會自動生成）。例如：

publicclassSaleTestextedsTestCase{//…//測試Sale.makeLineItem方法

publicvoidtestMakeLineItem(){//步驟1:創(chuàng)建測試固件,約定命名為‘fixture’,//通常定義為實例字段而非局部變量.Salefixture=newSale();//設置輔助測試的對象

Moneytotal=newMoney(7.5);Moneyprice=newMoney(2.5);ItemIDid=newItemID(1);ProductDescriptiondesc=newProductDescription(id,price,“product1”);//步驟2：執(zhí)行測試方法makeLineItem

fixture.makeLineItem(desc,1);

fixture.makeLineItem(desc,2);//步驟3：評估結果，驗證結果是否為7.5，

//對于復雜的評估可能有很多assertTrue語句

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

只有在編寫完testMakeLineItem()測試方法之后,才開始編寫Sale.makeLineItem方法,并且要通過這一測試。所以才叫測試驅動開發(fā)或測試優(yōu)先開發(fā)。5.IDE對TDD和xUnit的支持大多數(shù)IDE都會對xUnit提供支持，例如，Eclipse支持JUnit。其中的JUnit包括可視化的提示，即當測試通過后，將會顯示綠條。由此產生了TDD的一句俗語：保持狀態(tài)條為綠色就是保持代碼的純凈見下圖：21.2重構

1.什么是重構?

重構是重寫或重新構建已有代碼的結構化和規(guī)律性方法，但不會改變已有代碼的外在行為。而是采用一系列少量轉換的步驟，并且每一步都結合了重新執(zhí)行的測試。不斷地重構代碼也是XP的一個實踐，該實踐也適用于所有迭代方法，包括UP。重構的本質是一次實行一小步保留行為的轉化。每次轉化都稱為重構。每次轉化之后要重新執(zhí)行單元測試，以保證重構不會導致錯誤。2.重構的活動和目標*去除冗余代碼*改善清晰度*使過長的方法變得較短*去除硬編碼的字面常量*更多…

進行良好重構的代碼應該是簡短、緊湊、清晰的且沒有冗余。不具備這些品質的代碼是壞味代碼（codesmell）。壞味代碼不見的就是錯誤代碼。惡臭代碼（codestench）是真正要清理的垃圾代碼。

重構正是對壞味代碼進行矯正。與模式類似，重構也有名稱，大約有100多個已命名的重構。例如：*提煉方法（ExtractMethod）:將較長的方法轉化為較短的方法。*提煉常量（ExtractConstant）:使用常量變量替換字面常量。*引入解釋變量…*使用工廠方法代替構造器調用…

等等。

3.示例

1)描述提煉方法示例該示例中所列的Player類中的takeTurn方法,其中在代碼的開始部分完成了拋擲子和在循環(huán)中計算總點數(shù)的操作。這段代碼本身是獨立和內聚的行為單元，我們可以將這些代碼提煉為私有的幫助者方法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作為藍圖:適用與代碼和圖形的生成。利用工具，使用相對詳細的圖形來指導代碼的生成。生成代碼以后，通常還需要開發(fā)人員添加大量細節(jié)。還可以從代碼生成圖形，用來可視化代碼庫。

3.UML作為編程語言:UML形式的軟件系統(tǒng)的完整的可執(zhí)行規(guī)格說明?？蓤?zhí)行代碼會被自動生成，或由虛擬機直接解釋。大部分UML工具支持第二種方法。22.2前向、逆向和雙向工程在CASE工具的領域中，前向工程是從圖形生成代碼，逆向工程是從代碼生成圖形。而雙向工程是則支持雙向生成。所有UML工具都聲稱支持這些特性，但大部分只能實現(xiàn)其中部分特性。因為多數(shù)工具只能完成靜態(tài)模型：可以從代碼生成類圖，但無法生成交互圖，或者可以從類圖生成類的基本定義，但無法從交互圖生成方法體。

第四部分

細化迭代2:處理稅金和計價規(guī)則在細化迭代2中應用更多模式進行設計第23章引言1.我們已經學習了什么?

在第一次迭代中我們已經學習了基本的面向對象的系統(tǒng)分析方法和對象設計技術。2.第二次迭代中的學習重點是什么？進一步學習對象設計技術，并學習使用更多的設計模式來創(chuàng)建穩(wěn)固的設計，學習應用UML使模型可視化。3.在案例開發(fā)的迭代1中我們完成了什么?1）所有的階段性軟件都已充分地測試,包括單元測試、驗收測試、負載測試、可用性測試。

2）客戶定期地參與了對已完成部分的評估。開發(fā)人員已獲得對調整和澄清需求的反饋，客戶也認可了系統(tǒng)進一步完善的需求。

3）已經對已完成的系統(tǒng)進行了完整的集成和固化，使其成為基線化的內部版本。4.從迭代1到迭代2的轉移過程中有許多事情要做。為突出重點，不詳細討論。這些事情包括：*迭代計劃會議*使用UML工具從第一次迭代的源碼中導出圖形，并掛在墻上，作為溝通和新一輪迭代的起點。*對UI的分析和設計，以及對數(shù)據(jù)庫的建模和實現(xiàn)也在進行中。*舉行了新一輪需求討論會。5.迭代2的需求和重點在迭代2中我們將忽略需求分析和領域分析,把重點放在對象設計和模式應用上。在POS應用的第二次迭代中，關注處理銷售用例場景的如下需求：*支持第三方外部服務的變化，如處理支付和計算稅金等。*支持復雜的定價規(guī)則。*支持窗口刷新。這些需求在初始階段就已在用例和補充規(guī)格說明中提出了。第24章快速地更新分析目標快速地突出顯示一些分析制品的變更。1.用例需要更新嗎？就POS應用的案例來說，第二次迭代仍然是基于原有用例，因為在第一次迭代中我們只處理了主成功場景，且只處理現(xiàn)金支付。在第二次迭代中要處理稅金計算和計價規(guī)則問題。原有用例已反映這些需求，不必更新。

2.SSD需要更新嗎?

本次迭代要處理對具有不同接口的第三方外部系統(tǒng)（如稅金計算器）的支持，POS應用系統(tǒng)將與這些外部系統(tǒng)進行通信。增加邊界外的參與者，系統(tǒng)事件會發(fā)生變化，一些系統(tǒng)操作的要求也會變化。所以，SSD必須更新。下圖示出了對原有SSD的更新：

1）參與者的更新

2）系統(tǒng)操作流的更新圖中包括在下一次迭代要處理的信用卡支付需求。描述信用卡支付的SSD場景makeCreditPayment(credNum,expiryDate)reply=requestApproval(request)postReceivable(receivable)?actor?:CreditAuthorizationService?actor?:AccountsenterItem(itemID,quantity):NextGenPOS