將測試視為次等公民
如果你是位有經驗的工程師，你會在開始撰寫程式碼之前花一些時間思考程式的架構。針對程式設計方面，有一些概念已經重要到有自己的維基頁面了。像是：
第一項可以說是最重要的一點，它強迫你針對多個功能內相同的部分只撰寫一份共用的程式碼。根據你所熟悉的語言，你可能知道幾種設計模式可以用來達成這項原則。你甚至可能有針對所屬團隊如何維持這個原則的特別方針。
不過，因為某些原因，部分工程師不對軟體測試的程式碼應用這些原則。我見過有的專案程式碼架構非常好，但是測試卻充滿重複的部分，寫死的變數，剪貼的段落等等沒效率的狀況。這種狀況如果出現在專案程式碼內，會被視為無可推諉的失誤。
將測試視為次等公民是很沒道理的，因為長期來看，所有程式碼都需要維護。測試的程式碼也會隨時間需要更新與重構。它們的變數和結構也可能會改變。如果你寫測試時沒有思考架構，你是在功能程式碼已經積欠的技術債之外再多積欠一筆債務。
嘗試對撰寫測試的程式碼和撰寫功能的程式碼一樣用心。所有重構的技巧都可以用在測試的程式碼上面，開始可以先：
- 所有測試碼必須集中。所有測試應該用一樣的方法建立測試資料。
- 複雜的驗證方式應該萃取到共同程式庫實現
- 用太多次的 mock 和 stub 不能用剪貼的
- 類似的測試其初始環境應該要共用
如果你有部署靜態程序分析，程式碼格式或者程式碼品質檢查，那麼應該一併檢查測試程式碼。
簡單說，設計測試程式碼時應該要跟設計功能程式碼一樣用心。