範圍
開發人員-dev的對程式碼質量的保證方式，進行的程式碼級別驗證或者方法論驅動寫出質量能達到要求的程式碼，非測試人員範圍內的測試。
概念區分
單元測試 單元測試只測試程式單元自身的功能
整合測試 將所有模組按照概要設計要求組裝成為子系統或系統，驗證組裝後功能以及模組間介面是否正確的測試工作
tdd：方法論：寫程式碼只為修復失敗了的測試，基於單元測試
atdd：ATDD是一種團隊行為及過程，基於整合測試
例如：如果需要啟動spring容器來進行，已經屬於整合測試範圍，參考springdoc，spring－test包本身定義為整合測試，單元測試需要mock注入；
mock東西太多，所以我們會啟動spring容器來注入；但如果是tdd這種執行速度肯定不是我們能接受的。
方法論
現狀與問題
有鄙視沒有單元測試的程式碼，有覺得沒有測試就沒法寫程式碼的，但專案裡面很多處於中斷使用或者乾脆沒有。原因各種各樣，最後結果是沒有做或者中途停止。
常見如下：
沒有流程上統一約束，全靠開發自身決定
沒有可度量的方式，無法衡量
進度原因放棄，意味著價值比例總體還是體現佔比較小
簡單業務crud，很明顯，沒幾行業務程式碼，是否值得測試，大量依賴其他系統的測試又需要很多mock
整合測試呼叫外部系統無法反覆進行，對其他系統造成的髒資料問題
嘗試改進
透過測試增加程式碼質量，這件事本身可能會遇到很多難點，不是搭建一個demo的測試框架就可以解決。測試可能會促進你程式碼的改變，比如mock太多
提供統一框架，僅可能解決一些常見點，但具體問題還是一個個解決。ATDD要求整體流程配合，先做單元測試與整合測試的交集點。
簡單crud透過測成準備資料解決，複雜邏輯需要單元測試覆蓋，再整合測試僅可能覆蓋。整合測試一些點可以mock，比如外部呼叫。
準備結合我們專案選用測試整合如下：支援動態語言groovy並支援java
spock spring-test H2 junit jersey-test Mockito