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