TDD通過邊測試邊編寫程式碼，然後重構來防止重構所引起的錯誤
通過自動化測試和持續整合工具,隨時保持可以釋出
TDD第一步:
1. 需求分解
2. 將需求轉化成測試
3. 寫一個失敗的測試
4. 逐步通過測試，再寫一個測試
5. 開始消除重複程式碼 (由於這個時候有測試在了，所以不用擔心更改會引起整合錯誤)
看到這裡感覺在國內公司已經很難實現這個了，因為時間很難讓你去做這些事情
- 互動測試，並不驗證結果的正確性，而是驗證程式碼與其協作物件的互動行為的正確性
- 重構程式碼的時候不要直接用偵錯程式除錯，而是要把程式碼分為一個嚴格地軟體開發活動
1. 確定變更點
2. 確定測試點
3. 覆蓋測試點
4. 修改程式碼
5. 重構程式碼
先分析程式再寫測試再重構，以前都搞反了，先重構再寫測試所以很難去保證重構後代碼正確，因為思維方向就不對，先重構再測試時按照自己的思路來寫測試，更傾向於為了通過測試而寫測試，而 先測試再重構思路更傾向於根據業務來進行測試
- 資料庫測試，增量式DDL指令碼。一次只新增一個列或者一張表，每個步驟都可以回滾
- 資料庫測試使用指令碼或者其他方法新增進資料，然後進行測試