關於測試的一些思考（愚見）

單元測試與集成測試

關於Repository與Mapper單元測試與集成測試的權衡，理論上應由集成測試覆蓋mapper，單元測試覆蓋全部Repository。但實際開發中存在大量的Repository只是單純的簡單調用Mapper，無任何邏輯。對於這樣的Repository，若是開發時間緊張且需求變動不頻繁，能夠直接在Repository層直接編寫集成測試來保證測試覆蓋。但對於存在業務邏輯的Repository，仍建議使用單元測試進行覆蓋。且單元測試執行時間遠小於執行集成測試時間，編寫大量含有業務邏輯的Repository的集成測試會增長測試執行時間，致使開發人員下降對編寫測試的意願，增長流水線/CI/CD測試執行時間。

以此類推，建議對於簡單邏輯的代碼，無需花費過多的時間編寫重複邏輯的單元測試與集成測試。但對於較爲重要的系統組件代碼，仍建議進行高粒度和多層次的測試覆蓋。

測試對重構的影響

理論上對無測試或測試覆蓋度較低的代碼進行重構具備較大的風險，很難保證重構先後對外暴露功能與重構前徹底一致。但過於細粒度的測試（好比過多重複邏輯的測試：集成測試與單元測試重複，不一樣層次下集成測試屢次覆蓋）會大大增長重構時對於測試代碼的修改時間。從而致使下降開發人員重構意願以及增長重構所需時間。儘管不一樣層次的測試多重覆蓋能增長軟件的可靠性。但實際開發過程當中開發進度與軟件可靠性的權衡仍值得項目管理人員考量。對於高測試覆蓋率的重構，仍需測試人員進行重複測試。不能僅經過開發人員提供的測試報告就認爲重構先後軟件對外功能表現徹底一致。

人工審查代碼經常能檢查出測試代碼不能檢查出的問題

沒有100%可靠的軟件，僅靠開發人員編寫的單元測試、組件測試、集成測試不能徹底保證軟件的可靠性。哪怕對於測試覆蓋率100%的代碼，仍有可能存在未覆蓋到的業務場景。測試覆蓋只能保證每一行代碼都被執行到，每個分支都被覆蓋到。然而來自第三方的輸入卻沒法窮舉；多種分支的組合爆炸也使業務邏輯的徹底覆蓋會消耗開發人員大量的時間；業務系統上線後，也可能會出現各類意想不到的髒數據。不能徹底的相信開發人員測試覆蓋的報告（如Jacoco高測試覆蓋率，CI/CD變綠經過）就能保證其交付軟件的可靠性。所以，開發人員之間的Code Review，測試人員的手工測試，上線以前各部門之間的聯調仍有很大的意義。

TDD不是萬能的/反對教條主義

相比一些開發者對於TDD的狂熱，我認爲TDD並非萬能的。TDD是一種好的思想，可以幫助咱們拆分Task，劃分任務，理清需求，提高開發速度和軟件質量。但在實際開發任務中，我建議在保證軟件質量的前提下，無需嚴苛遵照TDD教條。好比對於算法等探索類項目，網絡爬蟲項目，細粒度的TDD開發只會下降開發效率，在測試與開發代碼之間反覆來回修改，徒耗時間。對於這類軟件，建議明確需求後先寫實現再補全測試。對於簡單邏輯，能夠在上層進行集成測試，無需自頂向下編寫大量僅僅簡單的直接調用的測試（如Controller->Service->Repository->Mapper）。對於一些過於嚴苛（在我看來）的教條，好比每次只編寫一條測試，而後紅綠實現；若是存在大量的相近測試場景，好比第三方輸入的驗證。若存在多種格式的校驗，我的認爲無必要單條測試與業務實現一對一進行，在明確Task後徹底能夠編寫多條test後一併實現，可以必定程度上避免業務代碼的反覆的簡單修改。TDD思想應該是保證軟件的可靠性和健壯性，不該是開發效率的阻礙。哪怕是徹底TDD驅動出的代碼，仍建議開發者人工的對邏輯進行審查。開發人員除了相信綠色的CI/CD，也應當相信本身的眼睛和大腦。

總之對於測試驅動開發而言，我的認爲沒有嚴格意義的執行教條，測試驅動開發是一種指導思想，是軟件質量的保證，但不該當是開發進度和效率的阻塞。