TDD的測試周期

# 測試驅動開發的編寫週期 （簡單的總體把握） 應該知道，沒有測試，就沒有功能代碼。測試驅動開發這種編程方式怎麼開始呢，那就是先寫一個新的測試 梗概如下： 1. 添加一個測試； ```java /** 要明白，現在這個測試裏所用到的類和方法都是不存在的。此時的測試甚至是編譯無法通過！ */ @Test public void testMovieRating() { Movie starWars = new Movie("Star Wars"); starWars.addRating(3); starWars.addRating(5); assertEquals("Bad average rating", 4, starWars.getAverageRating()); } ``` 2. **運行所有的測試**並查看失敗的； ```java /** 通過運行所有的測試，我們將會收到錯誤的信息提示，告訴了我們現在測試中存在的問題。可想見如下： 1.不存在Movie類 2.不存在addRating() 3.不存在getAverageRating() 如何解決？很簡單，按照提示，利用開發環境（編譯器如IDea）的強大功能迅速創建一個Movie類、方法。 */ public class Movie { public Movie(String name) {} public void addRating(int newRating) {} public int getAverageRating() { return 0;} } ``` 可以看見上面示例，所有的類和方法都是一個外殼，僅僅提供了外部行爲，內部的實現都是啞實現（有着返回值的方法都應該初步返回一個簡單的默認值！）。可想見，現在測試已經通過了編譯，再運行試試呢？失敗！提示我們：Bad average rating 期待的是4，實際的是0。 爲了使測試能夠通過，我們要“不折手段”了！既然想要4，那麼我們這樣做： ```java public int getAverageRating() { return 4;} ``` 現在，重新運行所有！測試呢：通過！！接下來要做的事情就是重構。 3. 對測試進行微小的改動；（書中原話——測試驅動開發 Kent Beck）【爲什麼不是對功能代碼進行微小修改，怎麼是對測試呢。。】 4. 通過**重構**去掉重複部分。（重複部分是指測試中的數據與程序之中的數據之間的重複） ```java /** 上面的功能代碼僅僅能完成那個期待4的測試。要想程序更加通用，接下來我們要泛化程序。 目標就是：讓程序能夠計算後返回電影評分的平均值。於是我們需要對程序裏的4這個常量做出思考： 要想泛化，就不能是常量（在這兒來看），所以要將它替換爲一個變量。 4從何來？可以想見：Movie類裏有着添加評分的方法addRating()， 所以4=(3+5)/2，即 平均分=總評分/評分次數。於是： */ public class Movie { private int totalRating = 0; private int numberOfRatings = 0; public Movie(String name) {} public void addRating(int newRating) { totalRating += newRating; numberOfRatings++; /** 從上往下，我們已經做了很多修改，記住：本應該修改就要重新測試，不過明顯從前面到這兒的修改， 不會出錯，那麼就省去每添一句新的代碼就重新測試這樣繁雜、死板的步驟吧。 不過現在我們已經設計到了一個方法的很多修改，我想是時候去運行一遍測試，祈禱不會出現問題吧。 */ //很好，，，測試可以工作！那麼繼續修改 } public int getAverageRating() { // return 4; return totalRating / numberOfRatings; // 剛纔我們已經把常量替換掉了！測試是否還能工作呢？運行，，通過！ /** 例子結束了，現在可以選擇一件事情，就是再添加一個測試，來驗證這個功能代碼是否真的被我們泛化了。 同時從這可以引申出，我們是否可以考慮在 return 4 的時候 就編寫這樣一個新的不同的平均分（比如測試平均分爲5）的測試，然後 爲了測試能夠工作，而對功能代碼進行泛化呢？ 所以這就有了選擇，看你自己，是否願意在 return 4 這樣一個常量的時候去 編寫一個同樣目的但測試的期待結果不同的新測試來強制提醒你將功能代碼泛化； 還是說願意在之後寫一個爲了檢驗是否泛化的新測試！ */ } } ``` 要明白：測試驅動開發的要點不在於採取了哪些措施，而**在於能夠取得這些微小進步本身**。（微小進步，有多微小呢？它甚至使得我們每一次的前進步伐控制在了幅度非常小，比如僅僅創建一個類的外殼、方法的外殼、字段的創建，這樣微小的前進步伐）因爲如能夠做到很小的改進，也一定可以完成你所需要規模的改進。 從上面例子歸納出：使指示條迅速變綠的三項策略： 1. **僞實現**：也就是那些微小進步的一個體現，通過創建出外殼，直接返回測試所期待的一個常量值來讓測試通過，然後逐漸用變量取代它！ 2. 使用**顯明實現**：直接鍵入真正的代碼實現。 3. 三角測量：目的是使得我們從不同角度去看待問題，從而得出結果，比如爲了寫出判斷兩個對象相等的功能代碼，我們還可以測試其不相等的情況！ 實踐中使用TDD時候，通常交替使用僞實現和顯明實現：當所有事情變得順暢時候，使用顯明實現吧；一旦測試未通過，意外出現了紅色指示條，那就**做好備份**回到僞實現！ # END 2019年11月3日，11點26分