4.4.1 調整周期
當你開發(fā)代碼的時候，你會設計一個應用程序變成接口，然后實現接口所提出的功能.當你進行單元測試的時候，你通過一個方法的API來驗證功能
4.4.2 TDD兩步走
前面，我們說過通過[測試，編碼，(重復)，提交]這樣一個流程，TDD加快了開發(fā)的周期.可問題在于這還遺漏了一個重要的步驟.更應該像這樣來運作:[測試，編碼，重構，(重復)，提交].
TDD的核心原則是:
1. 在寫新代碼之前寫一個失敗的自動測試.
2. 消除重復.
消除重復這個步驟確保了你寫的代碼不僅能通過測試，還具備可維護性.當你清除了重復之后，你能夠增加內聚，減少依賴.這些都是長時間保存而不變質的代碼的特點.
別的編碼實踐鼓勵我們編寫可預知改變從而達到可維護性的代碼.與他們不同的是，TDD鼓勵我們通過消除重復來編寫可維護的代碼.遵循這個實踐的開發(fā)者發(fā)現.有測試撐腰的并且劃分良好的代碼自然而然地可以簡單而且安全地承受改變.TDD給了我們自信，讓我們的問題解決，明天的問題明天解決.
4.5 在開發(fā)周期中的測試
在開發(fā)周期的不同地方和不同時間都會有測試.讓我們首先介紹一下開發(fā)生命周期，然后以它為基礎來決定何種類型的測試將在何時被運行.圖4.9給出了一個典型的開發(fā)周期，這樣的一個開發(fā)周期我們在小型或大型的開發(fā)中都廣泛應用.
生命周期被分成四到五個平臺(platform)
開發(fā)平臺: 這是編碼發(fā)生的場所.它包含開發(fā)者的工作站.它的一個重要的功能是提交(commit) 或check in(取決于所使用的術語);這樣的提交會有幾次，提交到你的公共源代碼控制管理工具.一旦你提交了，其他人能開始使用你所提交的東西了.但是只能提價能工作的部分也是很重要的.為了能知道它是否能正常工作， 一個典型的策略是采用自動構建，并且在每次上傳之后都運行它.
集成平臺(integration platform):這個平臺的目的是集成各個不同部分來構建應用程序而且要確保他們在一起能協調地工作.這一步是很有價值的，因為通常能在這兒發(fā)現問題.是因為它很重要.所以我們希望它能自動執(zhí)行.它被成為持續(xù)集成.并且，通過把自動構建應用程序作為構建過程的一部分，這也是可以達到的
驗收平臺/壓力測試平臺:取決于你的項目預算，這可以是一個或兩個平臺.壓力測試平臺在加載以后執(zhí)行應用程序，并驗證它是正確的.驗收平臺是項目的客戶.
成品(前)平臺
讓我們來看一下測試是如何在開發(fā)周期中發(fā)揮作用的.圖4.10說明了在每一個平臺上你能進行的不同種類的測試:
在開發(fā)平臺，你執(zhí)行邏輯單元測試(這些測試是能脫離環(huán)境進行的).這些測試執(zhí)行得非�？欤阃ǔ哪愕腎DE來執(zhí)行它們以驗證你對你的代碼所做得任何改動沒有損壞其他部分.在你提交代碼到你的SCM之前，你也可以通過你的自動構造來執(zhí)行它們.你應該執(zhí)行集成單元測試
集成平臺通常會自動運行構造過程，生成包，配置應用程序，并且執(zhí)行單元測試和功能測試，通常只是所有功能測試得一個子集在集成開發(fā)平臺下運行，因為相對于目標平臺，它只是一個簡單的平臺，缺少一些元素
在驗收平臺/壓力平臺上，你將執(zhí)行和集成平臺相同的測試，此外，你還要運行有壓力測試和負荷測試.驗收平臺同終的運行平臺非常相似，并且能夠執(zhí)行更多的功能測試.
盡管在預期的運行平臺下測試是一個很好的習慣.這樣的話會保證你是在一個一切都是正確的環(huán)境下校驗的.
4.6 小結
改變的步伐在加快，項目的時間框架在縮短，而我們需要對變化作出快速的反應.另外，開發(fā)過程正在改變----讓開發(fā)成為代碼的藝術還不夠，還應當讓開發(fā)成為編寫解決方案的藝術.
為了能跟上迅速變化的腳步，我們必須打破異步開發(fā)模式，在這種模式中，軟件測試是在開發(fā)完成以后由另一個獨立的團隊進行的，當改變和速度變得極為重要時，把測試留到后不那么合適了.
第五章:Junit自動化
在這一章里，我們將學習直接支持Junit的三個產品:Ant，Maven以及Eclipse.Ant和Maven是可以和任何Java編程環(huán)境配合使用的構建工具，Eclipse是一個集成開發(fā)環(huán)境(IDE).我們將會展示如何高效地結合使用Junit和這些環(huán)境，以及如何把Junit測試的執(zhí)行自動化.在這章的后，你將會知道，如何在你的電腦上配置環(huán)境來構建Java項目，包含如何執(zhí)行Junit測試以及如何創(chuàng)建Junit報告.
5.1 生命中的
為了使單元測試有效實用，它們必須是開發(fā)流程的一部分.大部分的開發(fā)周期開始于從項目源代碼中導出模板.在進行任何修改之前，謹慎的開發(fā)者會首先運行全套的測試工具.許多團隊有工作庫必須通過所有單元測試的規(guī)定.在開始你自己的任何開發(fā)前，你必須留意沒有誰違反這條”全綠規(guī)定”.你必須保證你的工作進展是已知的基線開始.
接下來是編寫新的用例的代碼.如果你是測試驅動開發(fā)的實踐者，你會先開始針對用例編寫新的測試.一般來說，這項測試表明你的用例未被支持.一旦你寫下了實現用例的代碼，狀態(tài)條將變綠，這樣你可以提交你的代碼了.
非TDD實踐者將實現用例并且編寫測試驗證.一旦狀態(tài)條變綠，代碼和測試可以提交了.
5.2 從Ant中執(zhí)行測試
編譯和測試像第三章中的DefaultController類這樣一個單獨的類是不難的.如果你的工具只是庫中Javac編譯器，那么編譯一個包含有多個類的大項目將是令人頭痛的.在數目不斷增加的類之間互相牽扯.于是越來越多的類得處于classpath上以便編譯器能找到它們.在每次構建中，只有一小部分類會被修改，該編譯哪些類也是問題.在編譯之后手動重新編譯你的Junit測試也同樣不方便.
幸運的是，以上問題的答案是令人難以置信的Ant.ant不僅是一個編譯程序的強有力工具，也是執(zhí)行Junit回歸測試的解決之道.
5.2.1 不可缺少的Ant
Apache的Ant是個讓你輕松地編譯和測試程序的構建工具.它是構建Java程序的事實標準.讓Ant如此流行的一個原因是它不僅僅是個工具;ant是運行工具的架構.除了可以使用Ant配置和啟動編譯器，你還可以使用它來生成代碼，執(zhí)行JDBC查詢，還有你將看到的Junit整套測試工具.
像許多現在的項目一樣，Ant使用一個XML文件來進行配置.這個文件也是構建文件(buildfile)，默認情況下被命名為build.xml.Ant的編譯文件描述了你想應用在你的項目中的每一個任務.任務可能是編譯java源碼.生成java文檔.
第二部分:測試策略
第一部分介紹用Junit進行單元測試的基本知識.然而，僅僅知道了Junit如何工作，或者如何把Unit用于簡單的例子，這都是遠遠不夠的.尤其是當把它用來測試一個真正的應用程序的時候.所以，單獨的Junit是不夠的，你需要發(fā)展出一套測試策略，使你能夠對一些真槍實彈的程序進行單元測試.主要問題在于如何孤立地測試每個部分.你在寫單元測試代碼時，想要一點一點地測試應用程序.那么，你如何把各個功能分離出來，從而獨立地測試它們呢?第2部分解決了這個重要問題..
第6章介紹了stub策略，它允許你孤立測試粗粒度的代碼部分.在第7章中，你會學習到叫mock objects的新技術，它可以進行孤立的細粒度測試.通過使用mock objects，你會發(fā)現這不僅僅是一種對代碼進行單元測試的新方法，而且還是一種新的編程方法.第8章把你帶入一個全新的領域---在容器中對代碼進行單元測試.現在，幾乎所有的代碼運行在可與之交互的某些容器中.你會學到，當J2EE代碼運行在它的容器中時，如何進行單元測試.你還可以通過與mock objects方法進行比較，從而了解這種策略的利弊.
讀完第二部分，你會熟悉用隔離方法對代碼進行單元測試的這三種策略了.你將做好準備，可以去應付我們旅行的后一步:單元測試各種類型的J2ee組件.
