關於測試驅動開發的思考
測試驅動開發（test driven develop）作為敏捷思想的重要組成部分，將開發和測試在同一時段完成，我認為是乙個很不錯的想法，尤其是經歷了無數測試後的返工以及開發中的疏漏後，測試驅動開發將作為以後開發工作中首當其衝的選擇。
據我所知，這裡有幾個誤區需要糾正，其一：敏捷開發的宗旨是高效和高質量，降低開發成本，它是有很多前提條件的，其中之一就是開發人員對敏捷開發的認識水平，所以並不是說敏捷就一定更優，如果能夠通過傳統方式達到相同的目的（明顯傳統開發有過多的理性行為假設，需要太多的改進），一樣是可行的；
其二，測試驅動開發並不是去準備無處不在的測試用例，不是說覆蓋所有的理論可能分支才算是測試，測試用例是為了無法通過測試而制定的，將測試人員的心態結合到開發人員中，是非常重要的優勢；
其三，文件是記錄方式，並不是交流方式，當文件成為交流方式時，要重新考慮團隊的開發狀況以及溝通成本；
其四，編寫測試用例很容易讓開發人員焦躁，從下往上的測試用例的編寫，對很多人來說可能是乙個災難，尤其在無法正確估計將來可能所帶來的成本時，pm很難說服開發人員去採用tdd的方式。這時候增加測試用例的優先順序，合理安排sprint顯的尤其重要。對於開發人員來說，一次從原則上很簡單的返工往往是毀滅性的，違背了的dry的原則，讓他們認識到這一點後，去重新理解tdd的價值，至關重要。
其五，如第四點所說，從下往上的測試用例的編寫對有些人是不適用的，按照使用者故事細分，為測試用例區分優先級別，制定更加有針對的測試用例，將會達到事半功倍的效果。
關於ui/ux的測試驅動開發方法，介面遷移的測試**量往往是重複而且冗餘的，很多時候沒有太大的意義，ui的測試方法往往通過資料跟蹤以及使用者反饋來進行評估。測試開發的增量更新有些時候非常不適用，對於ui/ux的設計開發方法，一開始的建模十分重要，，如何遷移是乙個方面，實際上遷移所帶來的問題是測試驅動開發針對ui設計的關鍵步驟，舉例說明，如果該介面增加乙個功能點，通過該功能點進行介面遷移的時，設計最不想看到的情形是什麼樣的。
利用敏捷開發重新認識工作成本的評估，是十分重要的，it行業工作量難以衡量並不能成為普遍加班的藉口。
《摘》關於測試驅動開發
測試驅動開發的基本過程如下 1 明確當前要完成的功能。可以記錄成乙個 todo 列表。2 快速完成針對此功能的測試用例編寫。3 測試 編譯不通過。4 編寫對應的功能 5 測試通過。6 對 進行重構，並保證測試通過。7 迴圈完成所有功能的開發。測試隔離。不同 的測試應該相互隔離。對一塊 的測試只考慮此...
測試驅動開發（TDD）的一些思考
最近在學習測試驅動開發 testdriven development，簡稱tdd 我的感受可以用這句來形容比較貼切，理想總是飽滿的，現實都是骨感的 當我說 理想總是飽滿的 時，那是因為tdd所致力於的目標所帶來的好處，確實很誘人。松耦合 不懼 重構等等，這些都是極具價值的。當我說 現實都是骨感的 時...
測試驅動的開發
tdd是軟體開發史上最重要的里程碑之一。tdd主要專注於自動單元測試，它的目標是盡最大限度自動化測試 如果 被改動，我們仍可以執行測試並捕捉可能存在的問題。換言之，測試對於已經存在的功能模組依然有效。比較兩個浮點數的大小 assert almost equal 如果兩個數字的近似程度沒有達到指定精度...