4.1.4 使得重構(gòu)可行
                沒有單元測試的話，要證明重構(gòu)是可行的將會是一件很困難的事，因為你總是可能損壞一些東西.為什么要花好幾個
小時的時間只是為了改進實現(xiàn)設(shè)計，改變一個變量的名字諸如此類的事情呢?單元測試能提供一個安全網(wǎng)，它能為你提供重構(gòu)的勇氣.

4.1.5  改進實現(xiàn)設(shè)計
                單元測試是客戶要進行的代碼測試的第一步.它們要求被測試的API是很靈活的，而且在孤立的狀態(tài)下也是能進行
單元測試的.你通常需要重寫你的代碼來使它能進行單元測試.

4.1.6 當(dāng)開發(fā)者文檔來使用.

4.1.7 非常有趣
                單元測試很容易讓人上癮.一旦你迷上了Junit綠色狀態(tài)條，離開它會變得很困難.它給你帶來了思想上的安寧.
剛開始的時候可能你會有所懷疑，但是一旦你迷上了測試，那么寫代碼而不寫測試是會變成一件不可思議的事.

4.2 不同種類的測試
圖4.2 大致地勾勒出了現(xiàn)在軟件測試地五種類型，有其他劃分軟件測試地種類的方法.

4.2.1 軟件測試的4種類型
我們已經(jīng)提到郭了單元測試所關(guān)注的是每一個不同的工作單元.但是當(dāng)幾個不同的工作單元合并到一個工作流中的
時候，測試此時將要發(fā)生的事情會怎么樣呢?工作流的后結(jié)果會是你所期待的嗎?應(yīng)用程序能夠滿足所有人的需要嗎?
以上每一個問題將會由一個不同的軟件測試類型來回答.針對討論的問題，我們可以將軟件測試分成四類:
                集成測試
                功能測試
                壓力/負(fù)荷測試
                驗收測試

集成測試
                單個的單元測試是一個很重要的質(zhì)量控制手段，但是當(dāng)幾個不同的工作單元合并到一個工作流中的時候，
將會發(fā)生什么事情呢?一旦你對一個類創(chuàng)建了一個測試并且已經(jīng)執(zhí)行了，下一步是關(guān)注其他方法和其他服務(wù).檢查組件之間的相互影響，這是進行集成測試.
                因為可能你想要集成的東西有很多，集成這個詞在不同的環(huán)境下代表了不同的事物.一些環(huán)境在表4.1中給出了.

功能測試
                在對象之間的測試交互作用是很重要的.但是結(jié)果是你想要的那個嗎/
功能測試在公共API的邊界處的代碼.通常情況下，這等于測試應(yīng)用程序用例.
功能測試通�？偸呛图�成測試結(jié)合在一塊的.

壓力/負(fù)荷測試
                應(yīng)用程序的功能能夠正確執(zhí)行是很重要的，但是當(dāng)多個用戶同時執(zhí)行時的效果又會如何呢?大多數(shù)壓力測試
檢驗應(yīng)用程序是否能在短時間內(nèi)響應(yīng)大量的用戶請求.通常，這是由一些特定的軟件來執(zhí)行.
比如:JMeter(http://jakarta.apache.org/jmeter).能夠自動地發(fā)送設(shè)定好的請求以及跟蹤應(yīng)用程序的響應(yīng)時間.通常請求是否被
正確的執(zhí)行是不被測試的.
                壓力測試通常在一個單獨的環(huán)境中進行.這種測試環(huán)境往往具有比典型的開發(fā)環(huán)境更多的控制.它必須跟運行的環(huán)境盡量相似.如果兩個環(huán)境很不一樣的話，測試也沒有意義了.
                其它類型的性能測試可以在開發(fā)環(huán)境下執(zhí)行.
從測試的角度看，用profiler能夠讓你先知先覺.幫助你在真正的測試之前發(fā)現(xiàn)一些潛在的問題.首先你必須能夠證明一個特定的瓶頸存在，然后你必須能夠證明這個瓶頸已經(jīng)被消除了.在兩種情況下，profiler都是重要的工具.
                單元測試也可以幫助你把一個應(yīng)用程序分割成一個個的自然的部分.一些Junit擴展，比如JunitPerf能構(gòu)幫助你建立一套跟你的單元測試相匹配的性能測試.你可以斷言一個重要方法不能花太長的時間，作為性能單元測試的一部分你還可以指定一段時間作為執(zhí)行的上限.當(dāng)應(yīng)用程序并重構(gòu)，如果有什么變化影響到你的話，這些測試會向你報警.
驗收測試
                應(yīng)用程序能夠運行流暢是很重要的，但是終一個問題是:這個應(yīng)用程序滿足了用戶的要求了嗎?驗收測試是這方面的測試.這些操作通常直接由用戶或者用戶的代理人來進行.驗收測試是確保應(yīng)用程序已經(jīng)滿足了用戶提出的任何要求.
驗收測試是所有其他測試的超集.

4.2.2 單元測試的3種類型
               本書主要內(nèi)容是通過程序進行自動單元測試.當(dāng)我們使用單元測試術(shù)語的時候，主要關(guān)注的是從內(nèi)部測試代碼.這種行為不可避免的和編寫代碼相互聯(lián)系并且同時發(fā)生.單元測試能夠確保你的應(yīng)用程序在一開始處在測試中.
                當(dāng)然，你的應(yīng)用程序應(yīng)該能夠經(jīng)受住其他各種軟件測試形式.從單元測試開始，以驗收測試結(jié)束.前面的章節(jié)介紹了對你的應(yīng)用程序應(yīng)當(dāng)做的其他類型的測試.
                許多應(yīng)用程序都被分成許多的子系統(tǒng).作為一個開發(fā)者，你想確保你的每一個子系統(tǒng)都能夠正確地執(zhí)行.當(dāng)你寫代碼時，你的第一個測試大概是單元測試.當(dāng)你寫了越來越多的測試和越來越多的代碼，你會發(fā)現(xiàn)，你需要開始添加集成和功能單元測試.在任何時刻，你都可能正在埋頭于邏輯單元測試，集成測試或者是功能測試.

4.3 判斷測試質(zhì)量

4.3.1 衡量測試覆蓋面
                一種衡量方法是數(shù)一下你的測試中用到了多少方法.這不會告訴你你是否在做正確的事情，但它能告訴你是否有
測試.
                沒有單元測試的話，你只能依靠應(yīng)用程序的公共API方法來寫測試.因為你不需要仔細(xì)研究應(yīng)用程序內(nèi)部并以此來創(chuàng)造測試，這些被成為黑盒測試，圖
               單元測試的創(chuàng)建依賴于對一個方法實現(xiàn)的了解.如果在這個方法中存在一個條件分支，你能創(chuàng)建兩個單元測試，每個分支各一個.你創(chuàng)建這樣的測試需要仔細(xì)研究那個方法，這是被稱為白盒測試.
有了白盒單元測試，要達(dá)到一個更高的測試水平變得簡單一些，主要因為你已經(jīng)訪問了更多的方法而且因為你能控制每個方法的輸入以及被調(diào)用的次級對象的行為(通過使用stub或者mockbojects你將會在后面的章節(jié)看到怎么做)，白盒測試能夠測試到包的保護方法和公有方法.

4.3.2 產(chǎn)生測試覆蓋情況報告
                對于Junit，可以找到一些工具幫你分析你的應(yīng)用程序并且提供一個關(guān)于你的應(yīng)用程序測試覆蓋情況的確切報告.圖4.7
給出了這樣的一個報告，這個報告是由Clover(http://www.coretex.net/clover)工具創(chuàng)建的.
                知道哪些類被進行了測試(DefaultController)，知道哪些類還沒有進行測試，這是重要的信息.但是如果能知道為什么DefaulgController只有94.7%的測試覆蓋那更好了.幸運的是，clover能夠在方法實現(xiàn)層次深入追蹤.
                知道哪些代碼還沒有進行測試是有好處的.盡管如此，一個好的測試工具(比如Clover)應(yīng)該提供歷史報告來顯示整個開發(fā)過程中的測試經(jīng)過，也應(yīng)該提供與你喜歡的構(gòu)建系統(tǒng)的集成.它也應(yīng)該有能力來停止構(gòu)建，如果標(biāo)準(zhǔn)沒有達(dá)到的話.
                在我們的項目中，我們喜歡進行一段開發(fā)迭代之后測試一下覆蓋百分率.我們調(diào)整構(gòu)建失敗標(biāo)準(zhǔn)，以使下一次迭代至少有與前一迭代一樣的覆蓋百分率.這個策略確保了我們測試覆蓋率能穩(wěn)步上升.
                雖然我們所展示的報告有幫助也很有趣，但是他們并不能告訴你你的測試有多么的好. 他們只會告訴你哪個方法已經(jīng)被測試過了， 哪個還沒有.算你的測試是完全錯誤的并且沒有測試任何東西，你的報告仍然還是一樣的!確保測試的質(zhì)量是很困難的，測試工具能提供一定的幫助.Jester 是通過對被測試代碼進行隨意的變動來工作的;它會驗證你的代碼在這種情況下是否依然能通過.如果他們通過了， 那意味著測試還是夠好.Jester通過多次反復(fù)來做這件事，它還會產(chǎn)生一個報告來揭示測試的質(zhì)量.
                記住的測試覆蓋并不能保證你的應(yīng)用程序得到了的測試，這一點是很重要的.你的測試覆蓋只是和你的測試一樣好!如果你的測試構(gòu)想很糟糕，那么你的應(yīng)用程序得不到足夠的測試，不管你進行了多少測試.

4.3.3 測試交互
                如果我們應(yīng)用白盒測試能達(dá)到更高的測試覆蓋，而且我們能夠生成幾個精彩的報告來證明這一點，那么我們還需要進行黑盒測試嗎?
                如果你想要完全的測試你的應(yīng)用程序，包括運行對象是如何相互影響的，你需要把黑盒子測試作為整個測試的一部分.
4.4 測試驅(qū)動開發(fā)
                在第三章中，你設(shè)計了一個應(yīng)用程序，而且快速地創(chuàng)建了幾個測試來驗證你的設(shè)計.當(dāng)你創(chuàng)建這些測試的時候，這些測試幫助改善了初的設(shè)計.隨著你創(chuàng)建更多的單元測試，正反饋的良性循環(huán)會鼓勵你盡早地編寫單元測試.很快，當(dāng)你設(shè)計實現(xiàn)的時候，要想知道你將要如何測試一個類變得自然而然.在這個方法論下，越來越多的開發(fā)者正在從利于測試的設(shè)計躍遷到測試驅(qū)動開發(fā).